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1  Introduction 

Security  critical  applications  are  now  within  reach  of  the  common  man.  We  no  longer  need  to  ex¬ 
amine  nuclear  power  plants,  armed  forces  facilities  or  air  traffic  control  towers  to  discover  software 
that  is  expected  to  comply  with  the  most  stringent  guarantees  of  correct  operation.  At  an  obviously 
more  modest,  personal  level,  it  has  become  critically  important  that  the  software  we  use  on  a  day- 
to-day  basis  protects  our  identity  as  well  as  our  financial  assets.  Current  smart  card  technology  is 
a  good  example  of  an  architecture  operating  at  this  level.  A  smart  card  is  a  plastic  card,  enhanced 
with  small  memory  and  processing  units,  commonly  used  to  identify  bank  account  holders,  com¬ 
pany  employees  or  club  members,  and  even  as  a  convenient  means  of  payment.  In  this  project 
we  have  explored  techniques  and  methodologies  to  increase  the  protection  of  confidentiality  with  a 
focus  on  smart  card  applications. 

Smart  cards  can  be  programmed  using  general-purpose  languages;  but  because  of  their  limited 
resources,  smart  card  programs  are  designed  to  perform  very  simple  tasks.  They  delegate  all  other 
work  to  external  systems  with  which  they  communicate  through  the  card  reader  (which  is  the  card’s 
only  interface).  As  a  consequence,  a  card’s  duty  is  confined  to  administer  small  but  very  delicate 
units  of  information,  like  PIN  numbers,  keys  and  account  balances,  all  of  them  critical  ingredients 
in  the  completion  of  tasks  like  payments,  cash  withdrawals  and  access  authorizations.  If  these 
information  units  were  to  reach  the  wrong  hands,  the  damage  to  the  card  owner  and  eventually  to 
the  service  providers  could  be  considerable. 

Although  it  not  difficult  to  find  other  examples  of  secrecy  critical  applications  for  the  individual, 
smart  cards  are  nonetheless  representative  of  a  range  of  information-enriched  devices  to  which  we 
may  entrust  (whether  aware  or  not)  our  identity,  access  codes  or  any  other  confidential  data  (e.g. 
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the  SIM  card  needed  to  operate  a  GSM  mobile  phone  is  a  smart  card  that  identifies  the  owner  of 
the  phone  line.  Similar  identification  units  are  being  proposed  to  interconnect  all  sort  of  personal 
gadgets).  The  more  we  rely  on  these  devices,  the  higher  our  vulnerability  in  cases  of  lost  confiden¬ 
tiality. 

What  makes  smart  cards  specially  suitable  for  this  study?  First,  smart  cards  feature  tamper-proof 
hardware  which  precludes  most  low-cost  physical  attacks,  and  a  simple  interface  that  reduces  the 
number  of  information  channels  to  consider.  Moreover,  the  existence  of  highly  adopted  standards 
and  common  high-level  card  operating  systems  extend  the  applicability  of  any  eventual  analysis  to 
a  wide  range  of  platforms.  For  the  researcher  there  is  even  one  further  challenge:  smart  cards  can 
host  several  applications  at  a  time,  adding  extra  complexity  to  the  study  of  confidentiality. 

In  this  report  we  examine  the  state-of-the-art  in  software-based  secrecy  verification,  and  discuss  its 
chances  to  scale  up  to  real  Java  Card  applications  (Java  Card  is  one  of  the  most  widely  deployed 
operating  systems/programming  infrastructures  for  smart  cards).  We  stress  the  need  to  cope  with  the 
one  aspect  that  sets  these  applications  apart  from  the  computer  systems  traditionally  studied  using 
information  flow  approaches:  namely,  an  overall  reliance  on  crypfographic  profocols  to  manipulate 
and  exchange  secret  information. 

Standard  models  of  secrecy  take  an  operating  systems  viewpoint.  Resources,  i.e.  files  and  processes, 
are  accessed  by  other  processes  on  behalf  of  users.  It  is  well-known  that  access  control  methods  are 
generally  insufficient  to  prevent  covert  channels  in  this  setting.  So  the  alternative  is  to  use  a  multi¬ 
level  security  model  (MLS)  and  define  an  informafion  flow  properly  over  if.  In  the  MLS  model,  the 
objects  and  subjects  of  the  system  are  classified  info  securily  levels  (or  clearances),  and  informafion 
flow  properfies  are  designed  to  forbid  all  flow  of  information  from  higher  to  lower  levels. 

Cryptography  does  not  fit  well  into  this  picture.  A  high-level  value,  once  encrypted,  may  be  ac¬ 
cessed  by  low-level  users  that  have  no  knowledge  of  the  decryption  key.  While  in  strict  information 
theoretical  terms  this  corresponds  to  a  flow  from  high  to  low  classification  levels,  in  practical  terms 
a  high-level  value  has  been  declassified,  i.e.  made  info  a  lower  classificalion  dafum.  Smarf  card  ap- 
plicafions  make  extensive  use  of  this  type  of  declassification  that  most  information  flow  fechniques 
(e.g.  noninterference  [16])  cannof  cope  wifh. 

Because  declassificalion  lies  oufside  mosf  information  flow  models  based  on  noninlerference  and 
MLS,  the  way  to  handle  it  has  mainly  been  to  delegate,  on  an  external  trusted  agent,  the  responsi¬ 
bility  of  deciding  whether  a  declassification  is  safe.  In  spite  of  this,  noninterference  models  make 
the  most  thoroughly  investigated  approach  to  information  flow  analysis.  Furthermore,  they  form  the 
basis  of  various  language-based  techniques  with  the  declared  potential  to  verify  real  code,  either  au¬ 
tomatically  or  semi-automatically  (see  [28]  for  a  recent  survey).  Therefore,  we  take  noninterference 
as  a  starting  point  for  our  investigations. 

We  organize  our  presentation  around  a  case  study,  a  realistic  Java  card  applet  implementing  the 
Needham-Schroeder-Lowe  public-key  mutual  authentication  protocol,  which  we  present  in  Sec¬ 
tion  2.  We  discuss  some  of  the  most  important  properties  that  such  implementation  should  satisfy 
to  guarantee  confidentiality  in  Section  3.  Facing  the  challenge  of  verifying  those  secrecy  proper¬ 
ties,  we  first  report  in  Section  4  on  our  experience  applying  a  noninterference  approach  to  our  code 
example:  the  decentralized  label  model  of  Myers  [25],  a  rich  instance  of  the  MLS  lattice.  Although 
our  example  does  not  require  the  full  expressive  power  of  decentralized  labels,  our  interest  in  this 
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model  is  easy  to  justify.  A.  Myers  and  his  colleagues  at  Cornell  have  developed  Jif  [24],  an  ex¬ 
tension  of  the  Java  language  with  a  powerful  static  and  dynamic  type  system  for  the  verification  of 
flow  properties  expressed  in  the  decentralized  label  model.  Besides  being  one  of  the  few  tools  that 
deal  with  a  realistic  programming  language,  Jif  is  also  rare  in  that  it  lets  developers  signal  explicit 
label  declassifications.  However,  being  based  on  a  noninterference  labeling  model,  it  provides  no 
assistance  in  checking  how  declassifications  affect  confidentiality. 

In  the  domain  of  smart  card  applications  we  can  expect  that  declassification  through  cryptographic 
operations  is  justified  by  some  cryptographic  protocol  that  the  code  is  designed  to  implement.  This 
observation  prompted  us  to  seek  a  way  of  explaining  the  correctness  of  declassification  operations 
by  first  verifying  the  correct  implementation  of  the  protocol.  In  Section  5  we  review  a  very  success¬ 
ful  approach  to  the  verification  of  functional  properties  using  the  extended-static  checker  ESC/Java. 
This  tool,  based  on  a  weakest-precondition  calculus  for  object-oriented  guarded  command  lan¬ 
guages  is  neither  specially  designed  for  Java  Card  nor  is  prepared  to  track  information  flows  (as  Jif 
does). 

Our  main  thesis  is  that,  in  order  to  scale  up  secrecy  verification  to  realistic  code  (that  makes  con¬ 
sistent  use  of  cryptography),  we  need  to  combine  the  two  approaches  above.  Tools  like  Jif  lack 
the  knowledge  of  the  implemented  protocol  to  reason  about  declassifications,  while  tools  designed 
for  the  verification  of  safety  properties  of  code  (of  which  ESC/Java  is  just  one  example)  lack  the 
ability  to  reason  about  information  flows.  Eurthermore,  we  sustain  that  such  a  combination  of  ap¬ 
proaches  can  be  given  a  formal  foundation  that  does  not  differ  much  from  recent  process-algebraic 
presentations  of  information  flow. 

In  Section  6  we  review  the  definition  of  Admissibility  [6,  II,  14]  which  is  an  information  flow  prop¬ 
erty  parameterized  by  a  dependency  specification.  The  latter  expresses  the  dependencies  between 
API  method  calls  that  produce  and/or  consume  secrets  as  stated  by  the  abstract  cryptographic  pro¬ 
tocol  that  the  code  should  implement  (A  more  detailed  discussion  of  admissibility  appears  in  [15], 
as  an  attachment  to  this  report).  The  practical  application  of  admissibility  to  our  case  studied  is 
discussed  in  Section  7.  The  presentation  uses  an  object-oriented  guarded-command  language,  es¬ 
tablishing  the  connection  with  tools  like  ESC/Java.  We  also  discuss  how  to  scale  the  approach  to 
Java  Card. 

Einally,  Section  8  mentions  related  work  and  Section  9  presents  our  conclusions.  Appendix  A 
contains  a  summary  of  the  activities  performed  within  the  SPC  01-4025  Mobile  Eanguage  Study 
project. 


2  Case  Study:  The  NSL  Authenticating  Applet 

In  this  section  we  introduce  a  case  study  that  is  used  through  this  whole  report  to  illustrate  and 
compare  the  different  approaches  to  the  verification  of  secrecy.  As  a  representative  of  the  applica¬ 
tions  raising  concerns  on  their  confidentiality  properties  we  discuss  (a  part  of)  a  Java  Card  applet 
implementing  a  well-known  and  well-studied  mutual  authentication  protocol. 
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2.1  The  Scenario 


Consider  a  smart  card  equipped  with  a  number  of  Java  Card  applets,  each  possibly  produced  by 
a  different  provider.  When  the  card  holder  feeds  the  card  into  the  card  reader,  which  of  all  those 
applets  gets  actually  executed? 

As  a  first  measure  of  protection,  an  applet  may  request  the  insertion  of  a  personal  identification 
number  (PIN)  before  performing  a  task.  In  order  not  to  exasperate  users  making  them  memorize  a 
different  PIN  for  each  applet,  the  Java  Card  architecture  provides  an  efficient  way  of  associating  a 
single  PIN  with  the  card.  Applets  can  demand  that  the  PIN  be  verified,  wifhouf  having  the  ability 
to  ever  set  or  update  the  PIN  value.  Such  an  implementation  is  routine  and  will  not  be  discussed 
further  in  this  report.  The  main  point  to  make  is  that  PIN  authentication  is  an  all  too  weak  security 
mechanism  that,  in  a  realistic  situation,  does  not  give  guarantees  to  the  card  holder  on  the  specific 
applef  fhaf  is  acfually  execufed  by  the  card  reader. 

In  fact,  the  user  may  never  know  which  applets  were  selected  by  the  card  reader.  All  that  matters 
is  that  this  cannot  be  abused,  and  that  no  applet  can  be  fooled  into  handing  in  secret  information  or 
enabling  services  for  recipients  other  than  the  card  holder.  On  the  side  of  the  service  provider  this 
amounts  to  correctly  authenticating  the  identity  of  the  card  holder,  so  that  the  right  user  gets  charged 
for  the  service.  On  the  side  of  the  applet  itself,  this  requires  authenticating  the  service  provider’s 
server  to  make  sure  that  no  third  party  gets  hold  of  the  secret  credentials  stored  in  the  applet. 

2.2  The  Protocol 

Our  case  study  applet  shows  just  one  way,  among  many  others,  to  accomplish  mutual  authentication 
between  an  applet  and  a  service  provider.  It  relies  on  an  implementation  of  the  Needham-Schroeder- 
Lowe  public-key  (NSLPK)  protocol  [23].  Besides  guaranteeing  mutual  authentication  between  two 
principals,  this  protocol  lets  them  agree  on  a  temporary  key,  which  could  easily  be  used  to  secure 
all  (further)  communications  in  the  current  session.  Figure  1  presents  NSLPK  in  the  customary 
notation  for  cryptographic  protocols,  where  A  stands  for  the  Applet,  S  for  the  service  provider’s 
server,  n  and  m  for  nonces,  and  for  the  encryption  of  plaintext  x  under  S’s  public 

key.  A  protocol  round  is  initiated  by  the  applet  when  it  sends  its  id  to  the  server.  Observe  that  an 
NSLPK  protocol  round  actually  ends  with  the  reception  of  message  (4).  We  have  added  message 
(x)  to  illustrate  how  the  applet  (and  the  server)  can  then  use  m  as  a  shared  key  for  the  rest  of  the 
session.  It  is  well  known  that  the  notation  of  Figure  1  is  far  from  formal,  in  the  sense  that  the 
pretended  secrecy  properties  of  the  protocol  may  fail  to  hold  for  some  of  the  interpretations  that  are 
possible  given  the  sequence  of  messages  above.  For  example,  nothing  in  the  figure  tells  us  what  a 
protocol  participant  should  do  in  the  event  of  receiving  a  malformed  or  out-of-order  message.  The 
intended  interpretation  for  the  NSLPK  protocol  is  that  in  all  those  cases  the  protocol  round  should 
be  immediately  terminated. 
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Figure  1:  The  Needham-Schroeder-Lowe  Public-Key  Protocol 

2.3  The  Applet 

In  the  Java  Card  execution  model,  a  card  and  the  applets  it  contains,  always  operate  in  client- 
server  mode.  Each  iteration  starts  with  the  card  reader  sending  a  request  to  the  Java  Card  Runtime 
Environment  (JCRE)  located  on  the  card.  The  request  takes  the  form  of  an  APDU  (Application 
Protocol  Data  Unit)  which  the  JCRE  can  either  process  or  forward  to  the  currently  selected  applet. 
When  a  response  is  available,  the  JCRE  passes  it  back  to  the  card  reader,  after  which  a  new  cycle 
may  begin.  The  APDU  commands  destined  to  the  JCRE  serve  the  purpose  of  installing  new  applet 
classes,  registering  applet  instances  and  selecting/deselecting  applets.  APDU  commands  directed 
to  the  applet  are  digested  by  the  applet’s  process  method. 

A  common  applet  development  strategy  starts  by  identifying  the  stages  an  applet  can  go  through 
during  its  lifetime,  e.g.  Installation,  Personalization,  Processing  and  Locked.  Since  we  are  more 
interested  in  how  the  applet  can  achieve  mutual  authentication  with  the  server  provider,  rather  than 
in  its  complete  behavior,  we  limit  our  attention  to  the  Processing  stage  and,  in  particular,  to  the 
stage  changes  caused  by  the  reception  of  APDUs  specifically  related  to  the  implementation  of  the 
NSLPK  protocol,  hollowing  the  methodology  proposed  in  [19]  we  present  a  finite  state  machine 
(ESM)  describing  the  state  transitions  produced  by  the  process  method  in  the  applet  at  the  different 
points  in  the  execution  of  the  NSEPK  protocol  (Eig.  2).  The  first  transition,  sendld,  emits  message 
(1)  and  leads  the  applet  to  the  WAITING  state.  The  reception  of  message  (2)  fires  fhe  sendChallenge 
fransifion  whose  response  to  the  card  reader  reflects  message  (3).  Einally,  the  sendSecret  transition 
is  fired  by  message  (4).  Its  result  is  the  transmission  of  message  (x). 

Such  a  finite  state  system  suggests  immediately  the  following  implementation  of  the  process  method: 
public  void  process(APDU  apdu) 

throws  ISOException,  APDUException,  CryptoException 

{ 

switch(state)  { 

case  STATE_INIT:  sendld(apdu);  break; 
case  STATE_WAITING:  sendChallenge(apdu);  break; 
case  STATE_CHALEENGING:  sendSecret(apdu);  break; 
default:  state  =  STATE_INIT; 

IS  OException .  thro  wit 

(IS 07 8 1 6.  S  W_EUNC_NOT_SUPPORTED) ; 
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Figure  2:  A  finite  state  machine  for  the  NSL  Applet 


} 

} 

If,  for  some  reason,  the  applet  ends  up  in  a  state  outside  those  in  Fig.  2,  an  exception  of  type 
ISOException  is  raised.  The  JCRE  is  then  responsible  to  translate  it  into  a  special  APDU  message 
containing  the  error  code  passed  as  a  parameter  to  the  throwit  method. 

Take  a  look  at  the  transitions  in  Fig.  2.  They  are  certainly  not  atomic  (e.g.  sendChallenge  takes 
care  of  receiving  message  (2),  processing  it  and  putting  together  message  (3)).  If  anything  goes 
wrong  the  applet  should  return  to  the  INIT  state.  In  fact,  what  we  have  is  an  FSM  as  it  appears 
in  Fig  3,  where  we  have  added  select  transitions  to  represent  the  re-selection  of  the  applet  (e.g. 
when  the  card  is  first  removed  and  then  reinserted  into  the  reader).  Observe  that  verifying  that 
the  applet  implements  the  FSM  in  Fig.  3  requires  checking  (a)  that  each  of  the  methods  sendid, 
sendChallenge,  sendSecret  and  select  correctly  establish  their  corresponding  target  state,  and  (b) 
that  all  error  situations  cause  a  transition  to  the  INIT  state  together  with  a  proper  notification  to  the 
JCRE  (in  terms  of  an  ISOException). 

Verifying  that  the  applet  code  (listed  in  Appendix  B)  actually  satisfies  these  requirements  is  not 
as  trivial  as  it  may  seem  due  to  the  possible  throwing  of  many  unchecked  exceptions  (In  Java 
Card,  as  well  as  in  Java,  unchecked  exceptions  need  not  be  mentioned  in  the  throws  clause  of  a 
method,  so  that  the  type-checker  would  tell  us  nothing  about  them).  Since  it  is  always  desirable  that 
the  card  reader  gets  a  proper  notification  of  any  errors  encountered  during  applet  execution,  card 
software  developers  look  for  guarantees  that  their  code  can  only  throw  exceptions  from  within  a 
very  small  set,  commonly  including  ISOException.  If  that  knowledge  is  available  the  verification  of 
error  transitions  in  Eig.  3  gets  considerable  simpler  (of  course,  we  still  need  to  verify  that  no  other 
unchecked  exceptions  can  ever  be  thrown). 

A  few  comments  on  the  applet  code  in  Appendix  B:  During  the  installation  phase,  after  the  class 
code  is  loaded  onto  the  card,  the  install  static  method  is  invoked  by  the  JCRE.  At  this  point  an 
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Figure  3:  A  finite  state  machine  with  error  and  select  transitions 


instance  of  the  applet  object  is  allocated  and  registered.  The  parameters  of  the  install  method  serve 
to  initialize  the  instance  fields  holding  the  applet  and  server  id’s  (which,  for  the  sake  of  simplicity, 
have  been  modeled  as  single  bytes).  This  is  ok  as  long  as  we  are  interested  in  having  at  most 
one  instance  of  the  applet  in  each  card.  The  applet’s  RSA  private  key  and  the  server’s  public  key 
cannot  be  loaded  using  this  method.  The  reason  is  a  mere  technicality:  RSA  keys  would  not  fit 
into  the  bArray  parameter  of  the  install  method  (it  cannot  hold  more  than  32  bytes).  In  practice 
they  must  be  uploaded  during  the  Personalization  phase,  which  has  been  left  out  from  our  code 
in  its  entirety.  However,  a  cipher  can  only  be  fully  initialized  after  getting  its  key,  which  means 
that  the  initialization  of  the  cipher  should  be  completed  during  the  Personalization  phase.  This 
would  be  a  serious  problem  if  we  wanted  to  execute  our  applet,  but  for  the  purpose  of  presenting 
and  discussing  secrecy  verification  we  can  simply  put  the  initialization  of  the  ciphers  in  the  applet 
constructor  assuming  that  the  keys  have  been  previously  loaded  into  the  fields  my.  private,  key  and 
server_public-key: 

protected  NSLClient(byte[]  bArray,  short  bOffset,  byte  bLength) 
throws  SystemException,  CryptoException 

{ 

enc  .init(server_public_key ,  Cipher. MODE  _ENCRYPT) ; 
dec  .init(my _private_key ,  Cipher. MODE  JDECRYPT) ; 

} 

3  Secrecy  of  Java  Card  Applets 

The  NSLPK  protocol  guarantees  the  mutual  authentication  of  principals  S  and  A  (cf.  Fig.  1)  and  the 
secrecy  of  the  agreed  session  key,  provided  that  the  private  keys  are  only  known  to  their  owners  and 
that  the  protocol  steps  are  followed  to  the  letter.  Achieving  this  in  practice,  using  a  programming 
language  with  such  a  complex  semantics  as  Java’s  is  harder  than  what  one  may  first  think.  There 


7 


are  just  too  many  possible  program  paths  to  consider,  exceptions  can  be  raised  almost  anywhere, 
nonces  can  be  reused,  messages  be  wrongly  constructed  or  interpreted,  ciphers  could  be  initialized 
with  wrong  keys,  etc.  There  are  also  many  ways  in  which  secret  information  could  be  leaked,  even 
when  the  programmer  is  not  trying  to  introduce  security  holes  on  purpose.  In  general  one  may  clas¬ 
sify  information  leaks  into  explicit  and  implicit.  An  example  of  an  explicit  leak  would  be  a  response 
APDU  containing  (part  of)  the  private  key  in  plaintext  form.  The  notion  of  implicit  leak  is  slightly 
harder  to  grasp.  It  is  characterized  by  the  encoding  of  secret  information  in  terms  of  variations  of 
observable  behavior.  Therefore,  the  nature  of  the  indirect  leaks  to  consider  goes  hand  in  hand  with 
the  observation  powers  we  assume  possible  (or,  at  least,  feasible  if  we  introduce  cost-efficiency 
considerations).  Examples  of  indirect  leaks  include  sending  different  seemingly  innocuous  mes¬ 
sages,  changing  the  time  it  takes  to  answer  a  process  APDU  or  the  probabilistic  distribution  of 
APDU  contents,  affecting  termination  behavior  and  even  modifying  power  consumption  patterns, 
all  depending  on  the  value  of  the  secret  to  leak. 

For  our  case  study  implementation  we  want  to  make  sure  that  it  preserves  the  secrecy  of  the  applet’s 
private  key  (field  my_private-key),  fhe  temporary  key  temp_key  and  fhe  secref  value  exchanged  in 
message  (x)  (i.e.  field  secret).  For  fhe  momenf  our  inferesf  is  in  defecfing  direcf  and  indirecf  possi- 
bilistic  channels  only.  We  do  not  seek  to  detect  timing,  probabilistic  or  power  channels.  Although 
this  would  be  desirable,  it  constitutes  a  longer  term  project.  Many  problems  posed  by  possibilistic 
channels  are  still  pending  a  solution  in  practical  terms.  Observe  that,  because  we  have  opted  not  to 
represent  the  Installation  and  Personalization  phases  of  the  applet’s  lifetime,  we  cannot  represent 
the  moment  some  of  these  pieces  of  confidential  information  enter  the  applet.  But  we  assume  that 
this  is  done  by  a  trusted  user  that  places  them  only  in  the  fields  menfioned  above.  The  temp,  key  is 
locally  generated  and  fhe  confenfs  of  fhe  secret  field  should  also  be  (fhis  is  nol  reflected  in  fhe  code, 
fhough). 

We  are  inferesfed  in  verifying  fhaf  fhe  apple!  described  in  Secfion  2  does  nof  leak  direcfly  or  in- 
direcfly  fhe  secrefs  menfioned  above.  Given  fhaf  fhese  secrefs  are  used  fo  compute  legal  APDU 
responses,  we  musf  in  fad  relax  such  a  sfricf  requiremenf.  In  fad,  whaf  we  need  fo  verify  is  fhaf, 
if  any  of  fhe  secrefs  is  ever  leaked,  fhen  fhis  happens  precisely  in  fhe  way  ordered  by  fhe  NSFPK 
protocol. 


4  Java  Information  Flow 

In  fhis  secfion  we  discuss  fhe  noninferference  approach  fo  information  flow.  In  parficular,  we  ap¬ 
ply  fhe  disfribufed  label  model  to  keep  frack  of  how  fhe  apple!  manipulates  ifs  secref  dafa.  This 
exercise  makes  heavy  use  of  fhe  declassification  capabilities  of  fhe  decenfralized  model.  This,  in 
furn,  motivates  some  later  commenfs  on  fhe  model’s  inadequacy  to  justify  declassifications  from  an 
informalion  flow  poinf  of  view. 

4.1  The  Model 

The  decenfralized  label  model  belongs  fo  fhe  class  of  multi-level  security  (MFS)  models.  Common 
fo  fhese  models  is  fhe  idea  of  using  an  exfended  language  semantics  where  principals  and  objeds 


(values)  are  labeled  with  security  clearances.  The  set  of  clearances  is  given  a  lattice  structure  under 
a  partial  order  relation  C  so  that  a  value  labeled  I  can  be  inspected  by  users  of  clearance  h  only 
if  (  C  /t.  Since  a  label  constitutes  an  abstraction  of  the  actual  semantic  value,  MLS  models  are 
quite  appropriate  for  the  application  of  diverse  language-based  techniques  to  the  verification  of 
information  flow  securify. 

A  sfandard  language-based  approach  consisfs  in  the  description  of  a  type  system  capable  of  de¬ 
termining  good  static  approximations  of  runtime  labels.  This  usually  requires  associating  labels 
to  positions  in  the  store  (object  references  and  fields  in  an  object-oriented  language),  and  defin¬ 
ing  ad-hoc  mefhod  signafures  to  describe  how  the  execution  of  a  method  affects  the  distribution  of 
confidential  data  in  the  store. 

In  the  decentralized  label  model  [24]  labels  are  sets  of  policies.  Each  policy  has  the  form  o  : 
ri, . . . ,  Tfi,  where  o  is  the  principal  that  owns  the  policy  and  gives  read  authorization  to  principals 
ri,  . . .,  Tn-  If  a  value  v  is  labeled  {o  :  ri,r2}  then  v  is  owned  by  o  and  can  be  read  also  by 
principals  ri  and  r2.  To  declassify,  the  owner  o  gives  read  access  to  more  principals.  To  read  a 
value,  a  principal  must  be  authorized  by  each  of  the  policies  in  its  label. 

Using  this  model,  Myers  has  developed  a  type  system  for  Jif  [8],  an  extension  of  the  Java  pro¬ 
gramming  language  that  incorporates  notation  to  label  field  and  mefhod  signatures.  Although  the 
decentralized  label  model  is  very  expressive,  our  case  study  needs  only  simple  policies.  Essentially, 
we  would  like  to  differentiate  two  security  clearances,  one  for  data  that  is  public,  and  the  other  for 
data  that  is  secret.  Public  data  is  marked  with  the  empty  set  of  policies,  {}.  Secret  data  is  marked  as 
owned  by  the  principal  P,  i.e.  with  label  {P  :}.  This  principal  represents  the  applet,  and  the  JURE 
is  expected  to  act  for  it,  so  that  invocations  of  the  different  applet  routines  (e.g.  install  and  process 
may  use  P’s  authority  to  declassify  information  when  the  protocol  permits  it.  In  Jif,  the  expression 
“ declassify  {e,  L)”  is  used  to  change  the  label  of  expression  e  into  L,  if  L  differs  from  e’s  label  only 
in  policies  owned  by  the  executing  process.  The  statement  “ declassify  {L)S”  executes  S  assuming 
the  entry  level  of  pc  (the  program  counter)  is  L. 

4.2  Jif  Annotation  of  the  NSL  Applet 

We  can  now  proceed  to  annotate  the  NSLClient  applet. 


Field  annotations:  To  start  with,  we  identify  those  applet  class  fields  whose  confenf  should  be 
protected.  In  Jif,  the  private  RSA  key  and  the  session  key  fields  are  annotated  as  owned  by  P. 
Instead,  the  default  label  of  a  class  field  is  {},  so  there  is  no  need  to  annotate  field  server,  public,  key. 

private  RSAPublicKey  server _public_key; 
private  RSAPrivateKeyjP:}  my_private_key; 
private  DESKeyjP:}  tempJcey; 

To  protect  the  secret  field,  we  not  only  give  it  label  {P  :},  but  also  change  its  type  to  byte{P  :}[], 
a  byte  array  where  each  element  is  also  owned  by  P  (cf.  [24]  for  details  on  label-parametric  types). 

private  final  byte{P:}[]{P:}  secret  =  ...  ; 
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Method  signatures:  In  Jif,  a  method  signature  can  be  annotated  with  security  labels.  As  with 
standard  type  systems,  this  allows  compositional  verification,  by  avoiding  the  analysis  of  the  method 
body  each  time  the  method  is  called.  The  label  immediately  after  the  method  name  is  an  upper 
bound  for  the  label  of  the  pc  at  invocation.  It  is  called  “the  end-label  of  the  method”.  The  label 
associated  to  each  formal  parameter  is  there  to  restrict  the  label  of  the  corresponding  actuals;  and 
the  label  after  the  colon,  the  end-label  ({P  :}  in  the  example  below),  conveys  the  information  that 
is  learned  by  observing  the  normal  termination  of  the  method. 

public  void  process{}(APDU{}  apdu):{P:} 

throws  (APDUException,  CryptoException,  ISOException) 
where  authority(P) 

The  where  clause  in  the  example  above  tells  Jif  to  make  sure  that  the  process  method  is  called  only 
if  the  caller  has  the  required  authority. 

Notice  that  it  is  expected  that  the  normal  termination  of  method  process  conveys  some  information 
labeled  {P  This  must  a  priori  be  considered  a  leak,  since  the  information  is  bound  to  reach  the 
card  reader.  It  will  be  our  task  in  the  coming  sections  to  justify  that  this  leak  is  not  dangerous. 

One  further  point:  Here  it  is  assumed  that  the  JCRE,  which  invokes  process,  has  the  authority 
to  declassify  data  owned  by  principal  P,  but  will  not  use  method  invocations  to  leak  information 
conveyed  by  its  pc.  It  is  beyond  our  intention  here  to  actually  verify  that  this  is  so,  since  the  JCRE 
lies  outside  the  subject  of  study.  A  similar  argument  is  used  to  annotate  the  Java  Card  API  (more 
on  this  soon). 


Label  propagation:  It  is  expected  that  partial  results,  computed  from  the  secrets  defined  above, 
are  sfored  into  other  class  fields: 

private  byte{P:}[]{P:}  outBuf,  nonce; 

That  the  nonce  must  be  kept  secret  is  clear,  but  notice  that  the  applet  is  responsible  for  its  generation. 
Therefore,  we  must  make  sure  that  each  new  nonce  value  is  not  manipulated  before  it  is  stored  in 
the  nonce  field.  We  do  this  by  attaching  label  {P  :}  to  the  random  number  generator  that  produces 
the  nonces: 

private  RandomDatajP:}  rand; 

This  is  not  enough,  though.  The  signature  of  the  generateData  method,  used  to  actually  obtain  a 
new  random  number,  must  reflect  the  idea  that  a  secret  RandomData  object  produces  secret  random 
numbers: 

/*  In  class  javacard.security.RandomData  */  abstract  public  void 
generateData(byte{this}[]{this}  buffer,  shortjthis}  offset, 
shortjthis}  length); 

Here  this  is  a  label  parameter  that  gets  assigned,  upon  method  call,  the  label  of  the  RandomData 
instance.  Since  the  field  rand  is  labeled  {P  :},  this  means  that  the  statement 

rand.generateData(nonce,  (short)O,  NONCE_LENGTH); 

forces  nonce  to  be  of  labeled  type  byte{P:}[  ]{P:},  as  wanted. 
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Ciphers:  Like  random  number  generators,  Ciphers  can  generate  secret  data.  This  can  happen  for 
example  if  a  public  ciphertext  is  decrypted  using  a  secret  key.  In  our  applet,  this  is  the  case  with 
cipher  dec  which  is  initialized  using  the  applet’s  private  key.  We  tell  Jif  about  this  property  of  the 
cipher  by  labeling  dec  (and,  for  the  same  reason,  cipher  sCipher)  with  {P  On  the  other  hand, 
the  enc  cipher  is  labeled  {}  because  it  is  only  used  to  encrypt  with  the  applet’s  public  key. 

private  Cipher  enc; 

private  Cipher{P:}  dec,  sCipher; 


As  with  class  RandomData,  the  API  class  javacardx.crypto.Cipher  must  be  annotated  to  propagate 
labels  appropriately.  There  is,  however,  two  small  complications:  a  cipher  must  be  first  initialized 
with  a  key;  and  then  the  security  level  of  the  output  produced  by  a  decryption/encryption  operation 
depends  not  only  on  the  level  of  the  key,  but  also  on  the  level  of  the  input  byte  array.  The  solution, 
for  both  methods,  is  the  same.  All  parameters  of  doFinal  and  init  must  be  bounded  by  the  label  of 
the  Cipher  instance. 

public  abstract  class  Cipherj 

public  native  short{this} 

doFinal(byte[]{this}  inBuff, 

shortjthis}  inOffset,  short{this}  inLength, 
byte{this}[]{this}  outBuff, 
shortjthis}  outOffset):{this} 
throws  (CryptoException); 


public  native  void  init{this}(Key{this}  theKey, 

bytejthis}  theMode) 

throws  (CryptoException); 

}  ' 

Observe  that,  in  Jif,  arrays  labels  are  invariant.  This  means  that  L  C  If  does  not  imply  that 
byte{I}[]  <  byte{I^}[] ,  where  <  is  the  subtype  relation.  Therefore,  Jif  would  reject  the  fol¬ 
lowing  statement 

dec.doFinal(inBuf,  (short)2,  KEY_LENGTH,  inBuf,  (short)O); 
because  the  type  of  inBuf  is  not  a  subtype  of  bytejP  :}[]. 

The  example  also  illustrates  a  very  convenient  feature  of  Jif.  API  classes  and  method  signatures  can 
be  given  without  having  to  annotate  method  bodies.  This  is  achieved  by  marking  those  methods  as 
native.  The  Jif  compiler  would  then  use  the  signature  for  the  analysis,  while  runtime  environment 
(not  described  nor  used  in  this  report)  can  still  use  the  original  API  classes  which  contain  the 
executable  code.  In  this  way,  one  looses  the  possibility  of  actually  checking  the  API  implementation 
(although  the  actual  code  can  be  added  later  if  wanted),  but  lets  one  get  started  with  an  initial  version 
of  the  full  Java  Card  API  with  minimum  effort  (Our  annotated  Java  Card  API  signatures  will  be 
made  available  from  the  project’s  web  site). 


11 


Class  annotations:  We  have  called  P  the  principal  that  owns  the  secret  data  stored  in  the  applet. 
How  could  one  change  that,  so  that  different  instances  of  our  applet  are  owned  by  different  princi¬ 
pals?  This  is  not  a  real  problem,  since  in  Jif  classes  can  be  parametric  on  labels  and  principals.  In 
fact,  P  is  just  a  parameter  with  which  we  have  parameterized  the  class: 

public  class  NSLClient[principal  P]  extends  Applet[P]  authority(P)  { 

}  " 

Notice  first  that  this  class  has  also  an  authority  clause.  This  says  that  the  process  that  creates  an 
instance  of  NSLClient[P]  must  have  P’s  authority. 

The  superclass,  i.e.  javacard.framework.Applet,  should  also  be  parameterized  with  P  because 
method  overrides  cannot  freely  modify  a  signature.  For  example,  we  must  allow  the  install  method 
to  operate  on  secret  data,  and  perhaps  have  different  termination  behaviors  due  to  it.  This  is  not  a 
problem  if  it  is  guaranteed  that  the  installation  can  only  be  done  by  principals  with  the  authority  to 
read  those  secrets,  which  is  reasonable. 

abstract  public  class  Applet[principal  P]  authority(P)  { 

pubUc  native  static 

void  install{}(byte[]{}  bArray,  short{}  bOffset, 
byte{}  bLength  ):{P:} 

throws  (ISOException,  SystemException,  PINException); 

}  ' 


Exceptions:  Exceptional  behavior  can  leak  information,  like  any  other  branching  of  control. 
Therefore,  Jif  makes  sure  that  all  possible  exceptions  are  accounted  for  in  the  signature  of  a  method. 
This  implies  that,  contrary  to  Java’s  approach,  Jif  requires  both  checked  and  unchecked  exceptions 
to  be  listed  in  the  throws  clause  of  method.  However,  this  leads  to  the  unnecessary  propagation  of 
begin-  and  parameter-labels  into  end-labels.  This  loss  of  precision  can  easily  result  in  the  rejection 
of  an  otherwise  completely  safe  method. 

To  overcome  the  problem  we  can  introduce  try-catch  statements  around  the  body  of  the  method  to 
prevent  Jif  from  assuming  the  possible  occurrence  of  an  exception.  Naturally,  in  order  to  do  such  a 
transformation  safely,  one  must  also  prove  that  it  is  really  the  case  that  the  exception  cannot  happen 
(This  problem  is  addressed  in  Section  5). 
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private  void  sendId{}(APDU{}  apdu) 
throws  (APDUException) 

{ 

try  { 

apdu.getBuffer()[0]  =  appletID; 
apdu.setOutgoingAndSend((short)0,  (short)  1 ); 
state  =  STATE_  WAITING; 

} 

catch  (NullPointerException  e)  {/*@  unreachable  */} 

catch  (ArrayIndexOutOfBoundsException  e)  {/*@  unreachable  */} 

} 

Declassifications:  Our  NSL  applet  uses  a  single  method  to  transmit  messages  (3)  and  (x)  (cf. 
Fig.  1).  This  serves  the  important  purpose  of  unifying  in  a  single  point  the  immediate  requirement 
that  only  public  information  is  transmitted  to  the  card  reader: 

private  void  sendMessage{}(APDU{}  apdu,  byte{}[]{}  buf, 

short{}  offset,  short{}  len) 


As  expected,  all  actual  parameters  to  the  method  are  requested  to  be  public.  Furthermore,  the 
declaration  includes  the  begin-label  {}  to  ensure  that  the  invocation  of  sendMessage  is  not  used  to 
leak  the  label  of  the  pc. 

This  decision  forces  us  to  take  action  to  make  Jif  type-check  the  two  calls  to  sendMessage  (in 
methods  sendChallenge  and  sendSecret),  as  they  happen  both  at  points  where  the  program  counter 
is  labeled  {P  :}  and  pass  field  outBuf.  Since  the  calling  methods  ran  with  the  authority  of  principal 
P,  they  can  perform  the  necessary  declassifications: 

declassify({}){ 

sendMessage(apdu,  declassify(outBuf,  {}), 

(short)O,  MESSAGE_LENGTH); 

state  =  STATE  CHAEEENGING; 

} 

4.3  Lessons  Learned 

Jif  operational  for  real  Java  Advantages:  progressive  annotation  of  API  files  Disadvantages:  buggy, 
still  in  development  also,  label  creeping  problem.  Exceptions.  Declassification  mechanism  is  ok 
for  data  values,  but  it  is  hard  to  declassify  the  effects  of  invoking  a  method  on  the  pc  and  exception 
paths.  Our  attempts  to  catch  exceptions  and  use  Jif’s  single-path  rule  (which  re-establishes  the 
entry  pc  after  a  sequence  of  statements  if  they  can  only  terminate  normally)  where  unsuccessful. 

As  mentioned  before:  no  way  to  justify  declassifications.  Uses  of  declassify  could  be  justified 
proving  appropriate  invariants,  that  should  hold  immediately  before  the  statements  requiring  de- 
classification  (for  example,  just  before  a  call  to  sendMessage). 
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The  complete  annotated  source  for  the  NSLPK  applet  appears  in  Appendix  C. 


5  Verification  of  Protocol  Implementations 


Much  has  been  done  in  the  business  of  verifying  software  for  compliance  with  high-level,  abstract 
specifications.  Although  the  issue  is  not  settle  yet,  there  exist  already  tested  approaches  that  happen 
to  be  quite  successful  when  it  comes  to  verifying  sequential  imperative  programs.  Object-oriented 
programming  languages,  specially  because  of  dynamic  binding,  brought  some  new  difficulties  into 
this  ground,  but  all  the  same,  we  can  now  find  good  verification  tools  to  test,  for  example,  that  our 
NSLPK  applet  implementation  behaves  as  described  by  the  FSM  model  of  Fig.  3. 

A  verification  approach  that  has  recently  been  applied  to  the  verification  of  protocol  implementa¬ 
tions  uses  the  Java  Modeling  Language  (JML)  and  diverse  tools  based  on  an  axiomatic  semantics 
of  the  Java  Card  language  [18,  17].  An  example  of  these  tools  is  the  ESC/Java  extended-static 
checker  [22].  In  order  to  apply  ESC/Java,  one  begins  by  annotating  the  (Java  source)  code  with 
class  invariants  and  method  pre-  and  post-conditions,  all  written  in  a  a  subset  of  the  JML  language. 
ESC/Java  then  applies  a  verification  condition  generator  to  produce  a  first-order  logic  formula  that 
is  subsequently  given  to  an  automatic  theorem  proven 

ESC/Java  is  neither  sound  nor  complete,  but  anyway  is  able  to  find  out  many  potential  problems 
in  code.  If  there  is  the  need  for  stronger  correctness  guarantees,  one  may  then  use  a  more  precise 
semantic  model  (e.g.  as  in  the  LOOP  tool  [30]).  However,  this  comes  at  the  high  cost  of  lost 
automation. 

Since  this  approach  has  been  described  in  detail  elsewhere  in  the  literature  (e.g.  in  [18,  17]),  we 
only  give  an  overview  here  on  how  it  is  applied  to  the  verification  of  the  NSLPK  applet. 

Our  initial  concern  is  to  make  sure  that  the  applet  implementation  behaves  as  mandated  by  the  FSM 
of  Fig.  3.  We  start  by  identifying  a  class  invariant  that  characterizes  the  possible  states  in  the  FSM, 
and  the  allocation  status  of  several  instance  fields  (obviously,  an  invariant  is  meant  to  start  holding 
only  after  the  execution  of  the  class  constructor): 

/*@  invariant 

@  (state  ==  STATE JNIT  \  \  state  ==  STATE _WAITING  \  \ 

@  state  ==  STATEjCHALLENGING) 

@  &&  inBuf  !=  null  &&  inBuf.length  ==  MESSAGE XENGTH 

@  &&  outBuf  !=  null  &&  outBuf.length  ==  MESSAGE XENGTH 

@  &&  nonce  !=  null  &&  nonce.length  ==  NONCE XENGTEI 

@  &&  dec  !=  null 
@  &&  enc  !=  null 
@  &&  rand  !=  null 

@*/ 


Consider  now  the  possible  transitions  originating  in  state  INIT  (cf.  Fig.  3).  The  execution  of  the 
sendid  method  should  leave  the  applet  in  the  WAITING  state,  except  when  an  exception  is  thrown. 
In  the  latter  case,  the  applet  should  remain  in  the  INIT  state.  This  is  specified  in  JML  with  the 
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following  annotation: 

/*@  requires 

@  apdu  !=  null  &&  apdu.  jiPDU state  ==  1 
@  &&  state  ==  STATE JNIT; 

@  modifies 

@  state,  apdu.buffer[*]; 

@  ensures 

@  state  ==  STATE_WAITING; 

@  exsures  (Exception)  state  ==  STATE  JNIT; 

@*/ 

private  void  sendId(APDU  apdu)  throws  APDUException  {  . . .  } 

There  are  four  clauses  in  this  JML  annotation:  The  first  one,  a  “requires”  clause,  describes  the 
method  precondition,  and  the  “modifies”  clause  lists  the  object  fields  and  references  that  may  be 
modified  during  the  execution  of  the  method.  The  last  two  clauses,  “ensures”  and  “exsures”,  de¬ 
scribe  the  state  that  should  hold  after  normal,  resp.  exceptional,  termination,  provided  that  the 
precondition  held  at  the  time  the  method  was  invoked.  In  this  case,  the  specification  states  that  the 
sendld  method  should  be  passed  a  non-null  APDU  and  should  be  invoked  from  state  INIT.  If  that 
is  the  case,  this  method  will  either  terminate  normally  in  state  WAITING,  or  exceptionally  in  state 
INIT,  or  it  will  not  terminate  at  all. 

Actually,  checking  that  our  NSLPK  applet  implementation  respects  the  transitions  in  the  FSM  of 
Fig.  3  gains  us  little  headway  for  the  verification  of  confidentiality.  But  it  definitely  helps  rule  out 
several  execution  paths,  and  with  them,  its  becomes  possible  rule  out  leaks  that  otherwise  may  be 
considered  plausible.  If  we  go  back  to  the  Jif  model  of  the  previous  section,  we  can  now  confirm 
fhaf  all  the  empty  exception  handlers  we  introduced  then  do  not  really  change  the  behavior  of  the 
program.  ESC/Java  can  show  that  the  corresponding  exceptions  are  never  thrown. 

A  more  demanding  task  concerns  the  justification  of  the  declassification  statements  we  introduced 
in  the  Jif  model.  These  come  in  two  flavors:  Firsf,  value  declassificalions,  like  in  the  expression 
declassify(outBuf,  {}).  The  idea  here  is  to  prove  an  invariant  at  this  precise  program  point  to  show 
that  every  time  the  outBufis  declassified,  ifs  value  agrees  with  what  the  protocol  mandates  of  the 
corresponding  response  APDU.  The  second  declassification  flavor  corresponds  fo  fhe  declassifica¬ 
tion  of  the  pc  label,  like  in  the  statement 

declassify({}){ 

sendMessage(  ...  ); 

} 

For  this  case,  it  does  not  help  to  prove  an  invariant  at  the  precise  declassification  point.  Indeed  the 
pc  could  have  gotten  its  high  level  time  before  in  some  execution  path  leading  to  this  point.  The 
way  to  handle  this  case  is  to  identify  all  points  of  control  branching  and,  again,  proving  that  they 
occur  according  to  the  protocol. 

Actually,  the  latter  approach  is  needed  also  to  justify  the  end-labels  given  to  methods  process, 
sendChallenge  and  sendSecret.  In  all  those  cases  the  end-label  is  {P  :}  which  indicates  that  the 
normal  termination  of  these  methods  may  leak  secret  information.  Obviously,  our  job  would  not  be 
complete  if  we  did  not  justify  them  as  admissible  declassifications,  occurring  in  accordance  to  the 
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protocol.  To  do  this  we  need  to  justify  all  branching  of  control  due  to  exception  throwing,  which 
calls  for  a  similar  approach  as  for  the  declassify  statement  (but  notice  that  Jif  provides  no  statement 
for  the  explicit  declassification  of  a  method’s  end-label). 

The  full  source  for  the  NSLPK  applet  that  is  listed  in  Appendix  D  collects  the  ESC/Java  annotations 
discussed  so  far.  From  this  point  onward  the  study  of  the  NSLPK  applet  should  proceed  with  the 
introduction  of  all  the  necessary  invariants  and  their  (usually  needed)  strengthening  in  ESC/Java. 

It  is  our  opinion  that  the  present  examples  have  made  the  case  for  a  verification  technique  for 
confidentiality  based  on  the  tracking  of  value  sensitivity  (as  provided  by  Jif)  and  the  justification 
of  declassifications  of  values  and  control  branching  by  protocol  implementation.  The  next  section 
presents  the  theoretical  background  for  such  a  combination  of  techniques. 


6  Admissibility 

We  have  argued  that  the  problem  of  confidentiality  in  the  context  of  applets  which  use  encryption  to 
communicate  with  the  outside  world  shows  the  inadequacy  of  standard  noninterference  models.  In 
this  section,  a  semantical  security  condition  is  proposed  to  express  and  reason  about  confidentiality 
in  such  a  setting* .  Typically,  the  applets  in  question  will  implement  some  sort  of  security  protocol, 
for  authentication,  secure  communication,  signing,  etc.  An  applet  claiming  to  implement  such  a 
protocol  may  in  fact  violate  confidentiality  for  a  number  of  reasons,  advertently  or  inadvertently. 
The  implementation  may  be  a  Trojan  and  use  various  forms  of  covert  and  subliminal  channels  to 
leak  sensitive  data.  More  typically,  though,  we  are  looking  to  catch  common  programming  errors 
such  as  missing  checks  on  nonces,  misused  random  number  generators,  wrongly  constructed  field 
values  and  representations,  etc.  leading  to  information  leaks  that  were  not  intended  by  the  protocol 
designers.  The  general  question  we  ask,  thus,  is  this: 

Does  a  given  implementation  of  some  security  protocol  contain  only  information  flows  allowed  by 

the  abstract  protocol  specification? 

Admittedly,  this  is  not  a  very  precisely  defined  question,  for  two  main  reasons: 

1.  In  practical  cases  it  is  not  at  all  clear  what  “the  abstract  protocol  specification”  is,  if  it  exists 
at  all.  It  may  be  described  as  part  of  an  IETF  RFC  or  other  standards  document,  as  a  sequence 
of  abstract  message  exchanges  in  the  usual  style  of  security  protocol  theory,  or  as  a  formal 
object  in  some  security  protocol  specification  framework. 

2.  Concrete  protocol  implementations  need  to  attend  to  a  variety  of  tasks  such  as  key  storage  and 
retrieval,  management  of  cryptographic  machinery,  memory,  buffer,  and  state  management, 
address  lookup,  error  handling,  and  much  else,  not  very  relevant  at  the  protocol  specification 
level. 

*This  brief  discussion  of  Admissibility.  A  more  detailed  presentation  can  be  found  in  an  accompanying  docu¬ 
ment  [15]. 
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Thus,  the  first  problem  is  to  find  some  way  of  specifying  the  intended  information  flows  af  the  API 
level.  For  this  purpose  we  introduce  a  simple  rule-oriented  notation  for  input/output  dependencies 
across  the  protocol  implementation  interface.  An  example  of  such  a  rule  might  be: 

send(n,  outchan)  ^  k  :=  k.ey (Bob)  Am  :=  receive(mc/jan)A 
V  :=  enc(m,  k) 

indicating  that,  if  upon  its  last  invocation  of  the  receive  method  with  argument  inchan  the  pro¬ 
tocol  received  m  (and  analogously  for  key.  Bob,  and  k),  then  the  next  invocation  of  send  with 
second  parameter  outchan  should,  as  its  first  parameter,  receive  the  encryption  of  m  with  key  k. 
In  addition,  a  dependency  specification  determines  a  set  of  method  invocations  presumed  to  cause 
new  secrets  to  be  created,  in  this  example  maybe  receive (inc/jan).  The  intention  is  such  that,  if 
(1)  is  the  only  rule  available,  then  the  only  admissible  invocations  of  send  which  depend  directly 
on  secrets  are  those  which  are  justified  by  the  rule.  Any  other  invocation  of  any  other  method  at  the 
applet  interface  which  depends,  directly  or  indirectly,  on  secrets  will  be  deemed  inadmissible. 

Observe  that  we  make  no  attempt  to  quantify  the  admissible  information  flows  in  other  ways  than 
through  direct  and  indirect  dependencies  between  method  invocations  at  the  applet  interface.  Only 
recently  have  researchers  began  to  apply  information  theoretic  or  complexity-based  concepts  to  give 
quantitative  measures  of  information  flow  in  computer  systems.  However,  these  approaches  are  not 
applicable  to  real  code  (cf.  [28]  for  an  indication  of  the  state  of  the  art  in  this  direction).  In  fact, 
making  the  confidentiality  analysis  of  some  given  protocol  implementation  hinge  on  an  information 
flow  analysis  of  the  protocol  itself  would,  in  our  opinion,  be  a  fallacy  of  method:  It  should  be  a 
matter  for  cryptographic  protocol  analysis,  not  program  analysis,  to  determine  whether  the  protocol 
is  correct,  and  for  program  analysis  to  determine  whether  the  protocol  specification  is  correctly 
implemented. 

The  enforcement  of  the  dependency  policy  proceeds  in  two  stages:  First,  data  flowing  through  the 
program  at  hand  is  annotated  to  make  it  possible  to  track  direct  flows  whose  secrecy  or  integrity  (in 
the  case  of  e.g.  public  keys)  needs  to  be  protected.  This  information,  then,  is  used  to  derive  a  ver¬ 
sion  of  the  admissibility  condition  introduced  first  in  [6],  which  captures  the  absence  of  undesired 
information  flows. 

6.1  Annotations  and  Commands 

For  the  purpose  of  illustrating  our  proposal  we  use  a  simple  sequential  language  (IMP).  Figure  4 
shows  an  IMP  implementation  of  the  Initiator  (the  Server  in  our  case  study)  in  the  Needham- 
Schroeder-Lowe  public -key  (NSLPK)  authentication  protocol  (cf.  Fig.  1).  As  discussed  in  Sec¬ 
tion  2,  an  implementation  needs  to  deal  with  a  lot  more  issues  than  what  are  explicitly  addressed 
at  the  protocol  specification  level.  Our  implementation  receives  the  identity  of  the  responder  from 
channel  RESPONDER  and  its  own  private  key  from  LOCAESKEY.  Constant  ME  is  the  Initiator’s 
id,  and  channel  PORT  is  used  for  all  incoming  network  communication.  Eunction  mkNonce  gen¬ 
erates  a  fresh  nonce,  key  fetches  a  public-key  from  a  local  store,  enc  and  dec  encrypt  and  decrypt, 
and  lookup  returns  the  IP  number  associated  with  an  agent  id. 

A  standard  operational  semantics  for  IMP  is  extended  to  an  annotated  form,  in  which  expressions 
and  values  are  annotated  with  the  method  invocations  causing  them  to  be  computed.  An  example 
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Program  NSLPK_Initiator: 


1 :  b  :=  receive  RESPONDER; 

2:  mySK  :=  receive  LOCALSKEY; 

3:  try 

4:  nonceA  :=  mkNonce(); 

5:  kb  :=  key  b; 

6:  send([ME;  b;  enc([nonceA;  ME],  kb)],  lookup  b); 

7:  r  :=  receive  PORT; 

8:  y  :=  dec(r[2],  mySK); 

9:  if  (y[0]  !=  nonceA  or  y[2]  !=  b)  then  raise; 

10:  send([ME;  b;  enc([y[1]],  kb)],  lookup  b); 

11:  send( '  Talking  to  '  +  b,  LOCAL); 

12:  catch 

13:  send( '  Error ' ,  LOCAL); 

Eigure  4:  NSLPK  protocol  -  sample  Server  implementation 


of  an  annotated  value  might  be 

347  :  enc(717  :  receive  a,  101  :  key  533)  , 

indicating  that  the  value  347  was  computed  by  applying  the  method  enc  to  a  pair  for  which  the 
first  value  is  717,  which  was  in  turn  computed  by  evaluating  receive  a  etc.  Since  the  dependency 
rules  make  reference  to  “the  last  value  returned  by  a  given  method  invocation”,  some  mechanism  is 
needed  to  keep  track  of  this  information.  So  the  configuration,  or  state  of  execution,  of  an  annotated 
command  c  will  be  a  triple  (c,  a,  s)  where  c  is  an  (annotated)  command,  a  an  (annotated)  store,  and 
s  is  a  context  mapping  method  invocations  of  the  form  f{w)  to  values,  the  last  value  returned  by 
evaluating  the  method  /  with  (annotated)  argument  w.  Transitions  will  have  the  general  shape 

{c,a,s)^{c\a’,s’) 

where  a  can  be  of  the  form  v  :=  f  w,  representing  the  invocation  of  method  /  with  argument  w 
and  return  value  v. 

6.2  Dependency  Specifications 

A  dependency  rule  such  as  (1)  will  have  the  general  shape 

/  e  t-  :=  /i  ei,  . . . ,  Xn-.=  fndn  when  -ip 
where  is  a  boolean  condition  and  the  are  expressions. 

A  dependency  specification  P  =  {T-L,  A)  puts  together  a  set  of  dependency  rules  A  and  a  set  T-L  of 
secret  entry  points  (e.g.  receive  LOCALSKEY).  The  dependency  rules  in  an  specification  limit 
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enc([na;  a],pkB) 
send([a;  b;  c],  d) 
dec{x,y) 
encdnb],  pkB) 


send([a;  b;  e],d) 


<—  b  :=  receive  LOCAL ,  pkB  :=  key  b  ,  na  :=  mkNonce() 
■(r-  c  :=  e'nc([na,a]^pkB) 
i—  y  '■=  receive  LOCALSKEY 

•<—  b  :=  receive  LOCAL ,  pkB  :=  key  b  ,  na  :=  mkNonce()  , 
m  :=  dec(x,y) ,  na'  :=  m[0] ,  nb  :=  m\l] ,  b'  :=  m[2] 
when  na  =  na'  Ab  =  b' 

■<—  e  :=  encdnb],  pkB) 


Figure  5:  NSLPK  -  Dependency  Specification  for  the  Initiator 


how  the  secret  information  is  to  flow  through  any  implementation,  from  the  moment  it  is  input,  till 
it  becomes  observable  by  the  execution  of  an  API  function. 

A  rule  in  the  specification  declares  an  action  a  =  {v  :=  /  e)  to  be  admissible  if  the  conditions  to 
the  right  of  the  arrow  are  satisfied.  Informally,  conjuncts  of  the  form  aj  :=  /^  are  satisfied  if 
variable  Xi  matches  the  last  result  returned  by  the  API  invocation  fi  e*.  The  boolean  expression  ip 
is  used  to  introduce  conditions  such  as  "state  =  STATE_INIT.”  Its  purpose  is  to  allow  for  limited 
observable  branching  in  the  processing  of  secrets.  We  will  then  write 

P,s\-  a  ok 

where  s  is  the  context  recording  the  history  of  API  invocations. 

Since  in  NSLPK  authentication  relies  upon  the  confidentiality  of  nonces  and  secret  keys  (cf.  Sec¬ 
tion  3),  PL  must  include  both  mkNonce()  and  receive  LOCALSKEY .  The  dependency  spec¬ 
ification  for  the  Initiator  is  completed  with  the  rules  in  Fig.  5.  Notice  how  the  fourth  rule  makes 
explicit  the  expected  nonce  check. 

Two  questions  of  interest  arise:  (1)  Are  all  direct  flows  through  some  given  applet  admissible? 
And  (2),  are  there  any  inadmissible  indirect  flows?  The  first  property  is  easily  formalized  as  a 

notion  of  flow  compatibility,  meaning  that  if  there  is  a  derivation  (q),  cro,  sq  =  -L)  — ^  •  •  •  — ^ 

{c„,  cr„,  Sn)  — (c„+i,  cr„+i,  then  P,  h  ok.  A  flow  compatible  program  should 
manipulate  secrets  just  as  stipulated  by  the  protocol.  To  see  why  this  is  needed,  consider  a  variation 
of  the  code  in  Fig.  4  where  we  have  added  the  line 

7.5:  r  :=  enc([nonceA;  mySK;  b],  MYPK); 

and  where  MYPK  is  the  Initiator’s  public  key.  Given  that  the  value  of  r  can  only  be  decrypted  using 
the  initiator’s  secret  key,  the  execution  of  this  statement  may  be  consider  innocuous.  But  further 
examination  shows  that  it  results  in  the  full  leakage  of  the  secret  key.  Fortunately, 

P,s  y-  enc([no  :  mkNonce();  ko  :  receive  LOCALSKEY ;...],  MYPK)  ok 


meaning  that  the  modified  implementation  is  not  flow  compatible. 
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6.3  Secret  Permuters 


To  get  at  both  direct  and  indirect  flows  the  idea  is  to  use  dependency  specifications  to  isolate  a  class 
of  “system  pertubators”,  permutations  of  secrets,  which  can  be  applied  at  the  external  interface  to 
internally  process  an  annotated  secret,  say  n,  as  if  it  really  had  some  other  value  rl.  If  the  pertubators 
adhere  to  the  constraints  given  by  the  dependency  specification,  and  if  care  is  taken  to  undo  only 
those  secret  permutations  for  actions  at  the  external  interface  that  are  admissible,  no  change  in 
observable  behavior  ought  to  ensue.  That  is,  a  change  of  observable  behavior  in  the  perturbed 
system  indicates  a  direct  or  indirect  flow  of  information  that  does  not  adhere  to  the  dependency 
specification. 


Technically,  a  secret  pemmter  for  a  given  dependency  specification  will  be  a  mapping  g  of  anno¬ 
tated  values  to  annotated  values,  satisfying  a  number  of  constraints  derived  from  the  dependency 
specification  at  hand.  Details  of  these  constraints  are  given  in  the  accompanying  paper  [15].  The  se¬ 
cret  permuter  is  extended  to  stores  and  contexts  in  the  obvious  way,  and  to  actions  using  a  condition 
along  the  lines 


g{s,a  =  v:=  f  w) 


v'  :=  f  g{w)  if  P,  s  h  a  ok 
a  otherwise 


That  is,  the  action  a  can  be  permuted  into  an  action  d  which  is  almost  identical  to  a  except  that,  in 
case  a  is  actually  admissible  in  the  current  context  (and  only  in  that  case)  the  choices  of  values  for 
secrets  (and  values  depending  on  secrets)  may  be  changed. 


6.4  Admissible  Information  Flow 

Using  secret  permuters  we  can  define  a  form  of  perturbed  command  c[g],  and  the  criterion  for 
admissibility  for  a  guarded  command  c  wifi  then  be  that 

{c,cr,s)  ~  {g{c)[g~\g{a),g{s)) 

where  ~  is  the  standard  Park-Milner  strong  bisimulation  equivalence. 

This  idea  of  characterizing  absence  of  information  flow  in  terms  of  invariance  under  perturbation, 
is  actually  quite  standard  in  information  flow  theory,  and  is  related,  among  others,  to  approaches 
based  on  process  equivalences  [10]  and  PER’s  [29]. 


6.5  Local  Verification  Conditions 

Applying  the  definition  of  admissibility  out  of  the  box  can  be  quite  cumbersome,  since  it  is  tanta¬ 
mount  to  searching  for,  and  checking,  a  bisimulation  relation.  In  case  the  observational  content  of 
control  branching  statements  (e.g.  conditionals  and  exception  throws)  is  allowed  by  the  dependency 
rules,  we  can  do  much  better,  since  only  data-related  properties  need  to  be  checked. 

As  before,  we  associate  a  set  of  secret  permuters  to  a  dependency  specification.  Each  secret  per¬ 
muter  g  in  this  set  can  be  extended  naturally  to  an  execution  trace  permuter  mapping  trace  Cia2  ■  ■  ■ 
to  trace  g{ai)g{a2) ....  If  for  each  secret  permuter  in  the  set,  every  possible  execution  trace  of  a 
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program  is  mapped  into  a  permuted  trace  visiting  the  same  program  points,  in  the  same  order,  we 
say  that  the  control  flow  of  the  program  is  not  affected  by  admissible  secret  permutations,  and  that 
the  program  is  stable. 

Our  main  verification  result  states  that  if  a  program  is  stable  and  flow  compatible  (i.e.  it  only 
produces  admissible  actions),  then  it  is  admissible.  The  result  is  important  because  it  provides 
justification  to  the  verification  strategy  that  was  sketched  for  our  case  study  in  Section  5.  Value 
declassifications,  like  that  of  the  output  buffer  (outBuf)  before  invoking  method  sendMessage,  cor¬ 
respond  to  the  verification  oiflow  compatibility,  whereas  program  counter  declassifications,  due  to 
branching  or  exceptions,  are  accounted  by  stability. 


7  Verification  of  Admissibility  in  Practice 

This  section  reports  on  our  efforts  to  develop  an  automatic  tool  for  the  verification  of  Admissi¬ 
bility  properties  of  a  simple  object-oriented  language  annotated  with  loop  invariants  and  method 
specifications.  In  the  following,  we  describe  the  syntax  of  the  model  language  together  with  its 
non-standard  axiomatic  semantics.  The  main  feature  of  the  semantics  is  that  it  records  and  in¬ 
forms  on  the  way  each  secret  value  was  obtained.  With  this  important  aid,  we  are  able  to  provide  a 
first-order  encoding  of  a  set  of  sufficient  conditions  for  Admissibility. 

7.1  OGCL:  An  Object-Oriented  Guarded-Command  Language 

We  illustrate  our  verification  technique  using  a  simple  but  rather  complete  implementation  lan¬ 
guage  which  we  call  OGCL.  It  extends  the  sequential  imperative  language  IMP  used  in  the  pre¬ 
vious  section  with  guarded-commands  and  object-oriented  features.  OGCL  is  also  a  variant  of 
ECSTATIC  [20],  a  simple  object-oriented  language  with  an  axiomatic  semantics.  This  choice  has 
allowed  us  to  reuse  and  benefit  from  the  approach  to  verification  proposed  by  Leino  et  al.  This  ap¬ 
proach  has  proved  successful  not  only  for  ECSTATIC,  but  also  in  the  implementation  of  verification 
tools  like  ESC/Modula-3  and  ESC/Java  [22]. 

An  OGCL  program  is  a  set  of  declarations  for  types,  data  fields,  methods  and  methods  implemen¬ 
tations.  Table  2  shows  a  simple  example  program  written  in  OGCL.  In  what  follows,  we  give  a 
quick  description  of  these  constructs,  referring  the  interested  reader  to  [20]  for  a  more  detailed 
explanation. 

Types  are  divided  into  simple  types  (bool,  int  and  nat)  and  object  types.  An  object  is  either  nil 
or  a  reference  to  a  set  of  data  fields  and  methods.  Eor  this  reason,  object  equality  is  understood 
just  as  reference  equality.  OGCL  programs  define  simple  subtyping  relations  as  orderings  over  type 
names.  The  primitive  object  type  obj  is  a  supertype  of  all  types,  and  nat  is  a  subtype  of  int.  The 
statement  “type  T  <:  U”  declares  T  as  a  subtype  of  (previously  declared)  type  U.  If  U  is  not 
present,  like  in  “type  T”,  then  T  becomes  a  direct  subtype  of  obj.  OGCL’s  static  type  system 
guarantees  that  whenever  an  expression  has  static  type  T,  then  every  value  it  may  evaluate  to  at 
run-time  is  either  nil  or  an  object  whose  allocated  type  is  a  subtype  of  T. 

A  data  field  declaration  “field  x:T  ^  U”  introduces  x  as  a  field  of  all  objects  of  type  T.  The 
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values  stored  in  such  a  field  are  of  type  U  and  are  accessed  by  means  of  a  “selector  expression”  x[t] 
where  t  evaluates  to  a  non-nil  object  of  type  T.  For  those  familiar  with  00-languages  like  C-i-i-  and 
Java,  a  selector  expression  x[t]  corresponds  to  the  expression  t.x. 

A  method  declaration  has  the  form 

method fonnal-outs  :=  m{formal-ins) 

requires  Pre 
modifies  w 
ensures  nPost 
except-ensures  xPost 

formal-ins  and  formal-outs  are  sequences  of  bindings.  Each  binding  x  :  T  declares  a  param¬ 
eter  X  to  be  of  type  T.  We  say  that  this  specification  is  given  at  type  %  where  Tq  is  the  type  of  the 
first  binding  informal-ins.  The  method  is  specified  using  three  predicate  formulas,  Pre,  nPost  and 
xPost,  and  a  list  of  selector  expressions  w.  The  free  identifiers  in  nPost  and  xPost  may  include 
initial-value  fields,  which  are  marked  with  a  0  subscript  and  refer  to  the  value  of  a  field  at  the  mo¬ 
ment  of  method  invocation.  A  method  declaration  lists  the  requirements  placed  over  all  its  correct 
implementations:  If  any  implementation  of  method  m  is  invoked  in  a  state  satisfying  Pre,  then  it 
either  does  not  terminate,  or  it  terminates  normally  in  a  state  satisfying  nPost,  or  exceptionally  (i.e. 
with  an  unhandled  exception)  in  a  state  satisfying  xPost.  Moreover,  every  correct  implementation 
of  m  can  only  alter  the  contents  of  object  fields  listed  in  w,  or  of  objects  it  creates  afresh. 

The  fourth  kind  of  declaration  in  OGCL  corresponds  to  method  implementations  with  the  form 
imT^X formal-outs  :=  m(formal-ins)  is  S 

where  S'  is  a  command  (explained  later).  If  a;  :  Iq  is  the  first  binding  in  formal-ins  then  this 
implementation  corresponds  to  the  specification  of  method  m  given  at  type  U,  where  U  is  the 
closest  supertype  of  Tq  with  such  a  method. 

7.1.1  Commands 

The  syntax  of  OGCL  differs  from  ECSTATIC’s  in  two  main  aspects.  Eirst,  OGCL  introduce 
sexcept-ensures  clauses  allowing  for  the  specification  of  exceptional  behaviors.  Then,  OGCL 
uses  a  command  set  derived  from  Dijkstra’s  guarded  command  language  (using  partial  commands, 
a  generalization  introduced  by  Nelson  in  [26]) 

The  OGCL  command  set  is  the  following: 
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Eormulas 

E 

::=  true 

false 

p(ei, . . . ,  Cn)  e  =  ee<ee@=  e 

E  AE 

1  1 

V  bindings.  E  3  bindings.  E 

Expressions 

E 

::=  true 

false 

nil  ra  X  E?  A  £■  -^E  \  E  =  E  \  E  <  E  \ 

E  +  E 

\E*E\E  —  E  \  x\E'\ 

Table  1 :  OGCL  formulas  and  expressions 


X  :=  E 
X  :=  new(T) 
x[E]  :=  E' 

assume  E 
assert  E 
raise 

if  SiD...Ds„fi 
s-  S' 

doi?  S  od 
try  5  catch  S' 

var  bindings  in  S  end 
var-list  :=  m{expr-list) 


simple  assignment 

allocation 

update 

partial  command 

assertion 

exception 

alternative  statement 

composition 

loop 

exception  handler 
block  statement 
method  invocation 


OGCL  borrows,  without  changes,  ECSTATIC’s  syntax  for  simple  assignments,  allocations,  up¬ 
dates,  compositions,  block  statements  and  method  invocations.  The  partial  command  (see  [26]  for 
a  thorough  description)  blocks  for  as  long  as  E  does  not  evaluate  to  true.  Together  with  the  alter¬ 
native  statement,  partial  commands  replace  ECSTATIC’s  conditionals.  Moreover,  they  can  easily 
express  Dijkstra’s  guarded  commands  too  (the  guarded  command  “q  — )■  S'i[]c2  — )■  S2”  is  written 
“if  assume  ci;  5i  []  assume  C2;  S2  fi”  in  OGCE).  The  command  assert  E  causes  the  program  to 
terminate  wrongly  whenever  formula  E  does  not  hold  at  this  point.  The  execution  of  raise  causes 
the  program  to  raise  an  exception,  which  is  always  unnamed.  An  exception  can  also  be  raised  im¬ 
plicitly,  e.g.  by  attempting  the  evaluation  of  an  undefined  expression.  Einally,  the  loop  construct 
incorporates  an  invariant  formula  E  to  help  automate  the  verification  process. 


7.1.2  Expressions  and  Formulas 

Table  1  presents  the  rather  standard  syntax  for  OGCE  expressions  (E)  and  formulas  (E).  Only 
predicate  @  =  deserves  some  explanation,  which  is  given  in  the  next  section. 

The  evaluation  at  run-time  of  an  expression  can  result  in  either  a  value  or,  if  undefined,  in  an  excep¬ 
tion,  and  has  no  other  side-effect.  Eormulas  include  first  order  quantifiers  and,  unlike  ECSTATIC, 
also  arbitrary  function  and  predicate  symbols.  Since  all  language  expressions  could  be  used  as 
terms,  OGCE  permits  formulas  like  “p{x  >  0)”  as  well  as  “y  >  z[t]”  (notice  that  in  the  first  case  > 
is  interpreted  as  a  function  symbol,  while  in  the  latter  case,  it  represents  a  predicate). 
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7.2  Axiomatic  Semantics 


In  ECSTATIC  (like  in  most  other  programming  languages  provided  with  an  axiomatic  semantics) 
the  semantics  uses  a  direct  representation  of  the  values  manipulated  by  legal  programs.  A  value 
stored  in  an  integer  variable  is  represented,  in  the  semantics,  just  as  an  integer  value.  Thus,  a 
integer  variable  x  is  mapped  into  a  variable  x  in  the  (first  order)  logic  used  to  describe  states.  This 
has  important  consequences.  For  example,  the  predicate  x  =  y  describes  those  program  states 
where  precisely  the  same  value  is  stored  in  variables  x  and  y.  However,  there  are  situations  where 
one  would  like  the  semantics  to  keep  some  extra  information  for  each  value  computed  by  a  program. 
The  definition  of  Admissibility,  for  example,  requires  that  we  annotate  values  with  their  history  of 
computation.  In  previous  presentations,  these  annotated  values  were  given  a  syntactic  form  making 
this  extra  information  explicit.  An  annotated  value  “5  :  read{in)”  corresponded  to  an  integer  5  read 
from  input  channel  in  using  method  read. 

In  our  axiomatic  semantics  for  OGCL,  logical  variables  range  over  “annotated  program  values.” 
However,  instead  of  relying  on  the  syntactic  shape  of  the  annotation,  we  use  specific  function  and 
predicafe  symbols  fo  describe  fhe  informafion  in  an  annofafed  value.  For  example,  we  use  funcfion 
val{)  fo  recover  fhe  program  value  confained  wifhin  an  annofafed  value.  Since  fhe  annofafions  of  a 
value  may  depend  on  fhe  annofafions  of  ofher  values,  we  use  predicafes  fo  relafe  fhem.  In  fhis  way, 
we  could  represenf  fhe  sfafemenf  “program  variable  x  confains  annofafed  value  5  :  read{in)”  as 
val{x)  =  5  A  read{ct{in),x).  We  use  funcfion  ct{)  fo  mark  a  value  as  being  a  consfanf  included 
in  fhe  program. 

Why  nof  use  fhe  simpler  x  =  5  A  read  (in,  x)?  Simply  because  if  x  =  y  fhen  we  could  conclude  fhaf 
read  (in,  x),  even  if  fhe  value  of  variable  y  was  obfained  from  complefely  differenf  sources.  Similar 
confusions  would  occur  befween  consfanfs  included  in  fhe  source  code  and  compufed  values. 

7.2.1  Transforming  Expressions  and  Formulas 

As  a  firsl  step  foward  fhe  definilion  of  an  axiomafic  semanfics,  we  embed  OGCL  expressions  and 
formulas  info  firsl-order  logic.  This  is  achieved  wifh  fhe  definition  of  functions  tr  and  pr.  Funcfion 
tr  converts  an  expression  into  a  first-order  term  over  annotated  values.  Function  pr  produces  a 
first-order  predicate  out  of  an  OGCL  formula.  Notice  that  a  comparison  predicate  (like  >  and  =)  is 
understood  to  compare  unannotated  values.  In  order  to  compare  annotated  values  for  equality,  we 
use  instead  predicate  @  =  . 

Function  tr  is  defined  over  OGCL  expressions  as  follows. 

•  For  any  consfant  c  (i.e.  false,  true,  nil ,  or  a  numeric  consfant),  tr(c)  =  ct(c) 

•  For  any  variable  v,  tr{v)  =  v 

•  For  any  selecf  expression,  tr{x[E])  =  select(x,  tr{E)) 

•  Boolean,  arifhmelic  and  comparison  operafors  are  fransformed  using  special  functions  (notice 
fhaf,  unlike  fheir  versions  in  [20],  fhese  special  funclions  operafe  on  annofafed  values.  See 
Section  7.2.4  for  an  example  of  how  these  functions  are  defined  wifhin  fhe  logic): 
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tr{Ei  A  E2) 
tr{->E) 
tr{Ei  =  E2) 
tr{Ei  <  E2) 
tr{Ei  +  E2) 


and{tr{Ei),  tr{E2)) 

not{tr{E)) 

equal {tr (El),  tr{E2)) 

less{tr{Ei),  tr{E2)) 

plus {tr {El),  tr{E2)) 


Function  pr  is  defined  over  OGCL  expressions  as  follows. 

•  For  any  constant  predicate  p  (i.e.  false,  and  true),  pr{p)  =  p 

•  pr  distributes  over  the  operators  -■  and  A 

•  pr(Q  bindings.  E)  =  (Q  vars.  types  ^  pr{E)),  where  Q  is  a  first-order  quantifier,  vars  = 
Vars{bindings)  and  types  =  Types  (bindings),  as  defined  in  [20] 

•  Comparison  predicates  are  transformed  into  the  corresponding  first-order  predicates  (c.f. 
function  tr): 

pr{Ei  =  E2)  =  {val{tr{Ei))  =  val{tr{E2))) 
pr{Ei  <  E2)  =  {val{tr{Ei))  <  val{tr{E2))) 

•  All  other  predicate  symbols  p  are  meant  to  describe  annotated  values,  therefore 

pr{p{Ei, . .  .,En))  =p{tr{Ei), . . .  ,  tr{En)) 

The  pre-defined  predicate  @  =  compares  two  annotated  values  for  equality  and  therefore 
needs  a  special  translation  rule 

pr{Ei  @=  E2)  =  {tr{Ei)  =  tr{E2)) 


7.2.2  Undefined  Expressions 

Occasionally,  some  expressions  are  built  using  operators  that  are  not  defined  over  all  possible  ar¬ 
guments.  For  example,  x[E]  is  not  defined  if  E  evaluates  to  nil  .  Under  these  circumstances,  we 
would  expect  that  the  evaluation  of  an  undefined  expression  results  in  an  exception.  Moreover,  we 
would  like  to  identify  the  conditions  under  which  this  can  happen. 

Our  approach  treats  an  undefined  application  of  an  operator  as  an  uninterpreted  function  of  its 
subexpressions.  Other  approaches  are  equally  possible.  Although  this  one  solves  the  issue  of  unde¬ 
fined  expressions  within  the  logic,  it  does  not  directly  help  us  detect  when  an  exception  should  be 
raised.  We  achieve  this,  instead,  with  the  aid  of  a  meta-function  (i.e.  a  function  defined  outside  the 
logic  level).  This  meta-function,  Defined{E),  returns  a  predicate  that  identifies  when  expression  E 
can  be  evaluated  without  generating  an  exception.  It  is  defined  inductively  over  OGCL  expressions. 
It  is  worth  noting  that  whether  a  expression  is  defined  or  not  does  depends  only  on  the  unanno¬ 
tated  values  that  it  operates  with.  This  is  reflected  in  the  use  of  function  val  to  translate  language 
expressions  into  first-order  logic.  For  example: 

Defined{x[E])  =  Defined{E)  A  val{tr{E))  /  nil 
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7.2.3  Verification  Conditions:  Conunands 


Following  Leino  [21],  we  define  the  weakest  liberal  precondition  of  command  S  and  predicates  (on 
the  post-state  of  S)  N  and  X,  as  the  predicate  wlp.S.{N,  X).  This  predicate  holds  for  those  initial 
states  from  which  S  either  loops  forever,  terminates  normally  in  a  state  satisfying  N  or  terminates 
exceptionally  in  a  state  that  satisfies  X. 

The  definition  of  wlp.S.{N,  X)  presents  no  major  difficulties  for  most  commands,  with  the  im¬ 
portant  exception  of  the  iterative  command.  The  standard  approach  consists  in  the  definition  of  a 
verification  condition  generator  vc  satisfying 

vc.S.{N,X)  =>  wlp.S.{N,X) 

and,  at  the  same  time,  making  use  of  the  extra  information  provided  by  loop  invariants  to  avoid  the 
difficulties  in  the  computation  of  weakest  preconditions  of  iterative  commands. 

For  some  commands,  the  definition  is  straightforward: 

vc.skip.{N,X)  =  N 
vc.raise.{N,X)  =  X 


which  indicates  that  skip  always  terminates  normally,  without  altering  the  state,  and  that  a  raise 
always  terminates  in  an  exceptional  state. 

Other  simple  cases  include  compositions,  alternative  statements,  exception  handlers,  partial  com¬ 
mands  and  assertions: 


vc.{S-,S').{N,X) 
vc.ii  5iD...DS„fi.(iV,X) 
tjc.try  S  catch  S'.{N,X) 
wc. assume  E.{N,X) 
VC.  assert  F.{N,  X) 


vc.S.{vc.S'.{N,X),X) 
vc.Si.{N,X)  A...vc.Sn.{N,X) 
vc.S.{N,  vc.S'.{N,X)) 
if  Defined{E)  then  val{tr{e))  N  else  X 
pr{E)  A  N 


Note  the  use  of  the  predicate  {if  x  then  y  else  z)  as  an  abbreviation  for  the  first-order  predicate 
{x  Ay)  \/  {->x  A  z).  The  violation  of  an  assertion  stops  the  program  at  once,  thus  the  precondition 
produced  by  vc  excludes  this  possibility. 


Simple  Assignment  For  a  simple  assignment  x  :=  E,  the  verification  condition  states  that  vari¬ 
able  X  gets  not  only  its  value  but  also  its  annotations  from  E 

vc.x  :=  E.{N,X)  =  if  Defined{E)  then  N[e/x]  else  X 


where  e  =  tr{E). 


Update  The  update  command  requires  more  care.  The  state  of  a  data  field  x  is  encoded  using  two 
functions  as  in  [20]:  select{x,t),  which  returns  the  value  of  field  x  at  object  f;  and  store{x,t,v), 
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which  returns  a  new  data  field  that  agrees  with  x  everywhere  but  possible  at  object  t,  where  it  hold 
value  V.  These  two  functions  are  related  by  the  axioms: 

Va;,  t,  t',  V.  val{t)  =  val{t')  ^  select  {store  {x,  t',  v),t)  =  v 

(2) 

yx,t,t',v.  val{t)  /  val{t')  ^  select  {store  {x,  t' ,v),t)  =  select{x,t) 

Note  how  only  the  value  of  the  object  reference  (i.e.  val{t))  is  needed  to  recover  the  contents  of  the 
data  field  at  that  object.  That  is,  the  annotations  of  t  are  not  of  use  here.  However,  the  values  stored 
in  a  data  field  carry  with  them  all  their  annotations. 

vc.x[E]  :=  E'.{N,X)  =  if  Defined{E)  A  Defined{E')  A  val{e)  /  nil  then 

N[store{x,  e,  e')/x] 
else  X 

where  e  =  tr{E)  and  e'  =  tr{E'). 


Allocation  The  verification  condition  associated  to  an  object  allocation  statement  is  almost  that 
in  [20],  though  with  a  minor  change  due  to  the  introduction  of  annotations.  We  show  its  definition 
here  for  completeness,  referring  the  reader  to  Leino’s  work  for  details  on  the  various  predicates  it 
relies  upon: 

vc.x  :=  ne'w{T).{N,  X)  = 

'ix,  alloc'.  {typecode{x)  =  tc$T  A  val{x)  /  nil  A  FieldReset{W,  x)A 
->isDecl{x,  alloc)  A  succeeds  {alloc,  alloc')A 

(yt.  isDecl{x,  alloc')  =  isDecl{x,  alloc)  V  f  =  x))  ^  R[alloc' / alloc] 

where  W  is  the  list  of  all  data  fields  whose  index  type  is  a  supertype  of  T.  The  resulting  verification 
conditions  says  that  new  registers  a  non-nil  object  reference  (x)  with  allocated  type  T  and  all  fields 
properly  initialized  {FieldReset{W,  x))  into  a  new  allocation  state  {allod). 


Block  Statement  The  verification  condition  associated  to  a  block  statement  coincides  with  that 
in  ECSTATIC: 

wc.var  bindings  in  S  end.{N,  X)  =  V  vars.  reset  ^  vc.S.{N,X) 

where  vars  =  Vars  {bindings)  and  reset  =  Reset  {bindings).  Function  Reset  was  defined  in  [20] 
to  encode  the  initial  value  of  local  variables,  and  Vars  extracts  the  list  of  variable  names  from  a  list 
of  bindings. 


Method  Invocation  To  illustrate  the  extraction  of  verification  conditions  for  method  invocation, 
consider  the  following  schematic  method  specification.  Method  m  takes  two  in-  and  two  out- 
parameters. 
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method  wO  :  ?70,  ul  :U1  :=  m(tO  :  TO,  tl  :  Tl) 
requires  Pre 
modifies  w 
ensures  nPost 
except-ensures  xPost 

The  verification  condition  for  method  m  is: 

vc.{vO,  vl  :=  m{E0,  E1)).{N,X)  = 

if  -<Defined{EO)  V  ^Defined{El)  then  X 
else 

V  to,  tl.  to  =  tr(EO)  Atl  =  tr(El)  ^  pr(Pre)A 
if  val{tO)  =  nil  then  X 
else 

(V  uO,  ul,  W,  alloc,  types  A  fieldtypes  A  succeeds  {alloc,  alloco)  A  Q 
{pr{nPost)  =>  N[uO,  ul/vO,  ul])A 
{pr{xPost)  ^  X))\W,  alloc/Wo,  alloco] 

where  W  is  Fields{w),  Wq  is  W  with  every  identifier  initial-valued,  types  =  Types {uO  :  UO,  ul  : 

Ul),  fieldtypes  =  FieldTypesfW),  and  Q  =  PostCondContrib{W,w),  as  described  in  [20,  p. 
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Loops  By  means  of  the  Invariance  Theorem,  which  approximates  the  weakest  liberal  precondition 
for  a  loop  provided  with  an  invariant,  we  can  immediately  derive  a  verification  condition  for  our 
loops: 


vc.dop  S  od.{N,X)  =  {inv  A  V  VF.  inv  ^  vc.S.{inv,  X)  A  {->grd{S)  N)) 

where  inv  =  pr{F),  W  is  the  list  of  all  fields  and  variables  modified  in  the  loop  body  S,  and  grd{c) 
is  the  guard  of  command  c.  Intuitively,  a  guard  corresponds  to  the  initial  states  from  which  a  partial 
command  can  execute  to  completion.  Formally,  grd{c)  is  defined  as  -iwp.c.{false,  false),  where 
wp.c.{N,  X)  is  the  set  of  initial  states  on  which  the  execution  of  c  terminates  normally  in  a  state 
satisfying  N,  or  exceptionally  in  a  state  satisfying  X.  Note  that  there  are  straightforward  syntactic 
restrictions  on  loop  bodies  that  greatly  simplify  the  computation  of  guards. 

This  completes  the  definition  of  vc  for  all  commands  in  the  language. 

7.2.4  Verification  Conditions:  Method  Implementations 

The  verification  condition  for  method  invocation  avoids  considering  the  actual  implementation  of 
the  invoked  method.  It  relies  instead  upon  the  assumption  that  all  method  implementations  comply 
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with  their  corresponding  specifications.  As  usual,  OGCL  merely  adapts  ECSTATIC’s  approach  to 
the  verification  of  method  implementations. 

Given  the  implementation 

impl formal-outs  :=  m{formal-ins)  is  S 

corresponding  to  specification 

m.eth.oA formal-outs  :=  m(formal-ins) 

requires  Pre  modifies  w 

ensures  nPost  except-ensures  xPost 

then  its  verification  condition  has  the  form 

BackgroundPred  Apr(Pre')  AYq  =  Y  A  val(self)  nil  =>  vc.SfnPost  A  Q,  nPost  A  Q) 

The  precise  details  are  to  be  found  in  [20].  The  formulas  Prd,  nPost'  and  xPost'  are  obtained  from 
Pre,  nPost  and  xPost  replacing  formal-outs’  and  formal-ins’  by  their  respective  names  informal- 
outs  and  formal-ins.  Predicate  Q  is  the  postcondition  contribution  resulting  from  the  modifies  lisf, 
and  Y  is  fhe  union  of  all  fields  in  w  and  all  fields  explicifly  modified  by  command  S.  As  before, 
alloc  is  fhe  allocafion  sfafe  of  all  objecfs;  and  self  is  fhe  firsl  name  in  formal-ins’ . 

The  background  predicate,  BackgroundPred,  collecfs  several  axioms  on  fhe  differenl  funclions  and 
predicates  used  in  fhe  encoding.  These  include  fhe  fwo  rules  relafing  funclions  store  and  select  (2), 
fhe  encoding  of  fhe  sublyping  relalion,  crileria  for  fhe  consistency  of  allocafion  slates,  elc.  The  main 
difference  wilh  respecl  lo  fhe  background  predicale  used  in  ECSTATIC  is  in  fhe  axiomalizalion  of 
funclions  operating  on  annolaled  terms.  To  illustrate  this  last  item,  consider  function  equal  which 
compares  annotated  values  for  equality. 

Eor  equal,  the  background  predicate  contains  the  axioms 

V  c,  d.  val{equal{c,  d))  =  true  V  val{equal{c,  d))  =  false 
y  c,d.  {v al {equal {c,d))  =  true)  =  {val{c)  =  val{d)) 

Similar  axioms  are  given  for  the  functions  introduced  in  the  translation  of  OGCL  expressions  (see 
definition  of  function  tr.  Section  7.2.1). 

This  concludes  our  overview  of  the  axiomatic  semantics  for  OGCL,  which  is  strongly  based  on  that 
of  ECSTATIC,  but  differs  from  it  in  the  necessary  handling  of  a  different  command  set  and,  most 
importantly,  the  notion  of  annotated  terms.  These  terms  represent  language  expressions  instead  of 
concrete  values,  adding  a  level  of  indirection  to  access  the  latter  (using  function  val). 

7.3  Verification  Conditions  for  Admissibility 

We  have  previously  introduced  the  notion  of  Admissibility  [6,  11,  14],  an  information  flow  properly 
meanl  lo  delermine  whelher  a  syslem  preserves  fhe  confidenlialily  properties  of  ils  specification. 
In  contrasl  wilh  mosl  informalion  flow  properlies  in  fhe  lileralure,  Admissibilily  does  nol  prevenl 
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in  general  the  leakage  of  information  but  forces  all  leaks  to  respect  a  confidentiality  policy.  Such 
a  policy  identifies  the  secrets  handed  to  the  system  by  its  environment,  and  establishes  precise 
conditions  under  which  these  secrets  may  be  leaked. 

In  this  section  we  show,  by  example,  how  to  encode  sufficient  conditions  for  the  verification  of 
Admissibility  over  implementations  written  in  OGCL.  Consider  this  (rather  artificial)  example.  A 
trusted  computing  base  provides  programmers  with  a  few  types  and  interface  methods  written  in 
OGCL.  All  data  is  communicated  to  and  from  the  environment  through  objects  of  type  Channel. 
The  data  thus  exchanged  is  of  type  int  or  Data.  Objects  of  type  Data  contain  two  data  fields: 
an  integer  field  info  containing  the  actual  piece  of  data,  and  a  boolean  field  public  which  is  true 
whenever  the  data  may  be  declassified.  Type  Data  possesses  only  one  method,  namely  process, 
which  in  some  obscure  manner  processes  the  data,  returning  a  new  data  object  and  deciding  whether 
the  processed  data  may  be  made  public  (i.e.  declassified).  Without  further  method  specifications, 
this  could  be  written  in  OGCL  as 

type  Data 

field  info  :  Data  ->  int 
field  public  :  Data  ->  bool 

method  e  :  Data  process (d  :  Data) 

ensures  fresh(e) 

For  type  Channel,  we  only  care  at  the  moment  about  two  methods:  Readsecret  reads  a  Data  object 
from  the  channel  which  it  marks  as  non-public;  and  writelnt  ]\xs,t  outputs  an  integer  on  the  channel. 
This  is  encoded  in  OGCL  as 

type  Channel 

method  d  :  Data  readSecret (ch  :  Channel) 

ensures  fresh (d)  and  public [d]  =  false 

method  writelnt(ch  :  Channel,  n  :  int) 

A  Confidentiality  Policy  We  want  to  test  implementations  using  this  interface  for  illegal  informa¬ 
tion  leakages.  These  implementations  are  allowed  to  invoke  the  interface  methods  at  will,  provided 
they  only  output  secret  data  (obtained  using  method  readSecret)  if  it  has  been  previously  processed 
and  deemed  public  (by  method  process).  According  to  the  definition  of  confidentiality  policies 
given  in  [11],  we  define  the  set  of  secret  entries  as  £■  =  {readSecret}  and  the  set  of  critical  entries 
as  C  =  {process}.  Then,  our  confidentiality  policy  has  the  only  clause: 

writelnt{c,n)  t—  rr  :=  readSecret  c'  A  y  :=  process  x  A  z  =  true  A  n  =  info[y] 


Admissibility  The  task  of  verifying  an  Admissibility  property  can  be  divided  into  two  subtasks. 
In  the  first  one,  we  annotate  secret  values  and  use  these  annotations  to  track  direct  information 
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leaks.  In  the  second  one,  we  rely  on  relabeling  functions  and  bisimulation  relations  to  exclude 
any  remaining  indirect  leaks.  Fortunately,  there  exist  sufficient  conditions  to  complete  the  second 
subtask  without  engaging  in  complicated  proofs  of  bisimulations.  Essentially,  it  suffices  to  prove 
that  the  flow  of  control  is  not  altered  by  permutations  of  the  secrets. 


Direct  Leaks  In  order  to  track  direct  leaks  of  information,  we  make  use  of  the  enhanced  ax¬ 
iomatic  semantics  of  OGCL.  Basically,  we  need  to  make  sure  that  secrets  get  properly  annotated 
at  entry  points  (£’)  and  that  these  annotations  are  carried  along  during  computation.  We  achieve  by 
modifying  the  postconditions  of  every  method  in  £■  U  C.  We  add  the  conjunct 

m(formal-outs,  formal-outs^  w) 

at  the  ensures  clause  of  every  method  declaration 

meth.od formal-outs  :=  m(formal-ins) 

requires  Pre  modifies  w 

ensures  nPost  except-ensures  xPost 

(Ohs:  Similar  conjuncts  should  be  added  to  xPost,  but  at  the  time  of  writing,  we  have  not  yet  worked 
out  a  proper  shape  for  those  conjuncts). 

For  our  example,  where  methods  raise  no  exceptions,  this  simply  requires  changing  the  specification 
of  methods  process  and  readSecret: 

method  e  :  Data  process (d  :  Data) 
ensures  fresh(e)  and  process (d,  e) 


method  d  :  Data  readSecret (ch  :  Channel) 

ensures  fresh (d)  and  public [d]  =  false  and  readSecret (ch,  d) 

Now,  given  that  the  annotations  (i.e.  the  predicates  introduced  in  the  previous  step)  are  carried 
around  together  with  the  values,  we  only  need  to  insert  an  extra  requirement  at  every  method  that 
outputs  information  to  the  environment.  What  is  required  is  that  the  method  invocation  be  consid¬ 
ered  admissible.  For  this  particular  purpose,  we  introduce  a  specification  predicate,  adm{). 

In  the  example,  we  just  modify  the  requires  clause  of  the  only  outputting  method. 


method  writelnt(ch  :  Channel,  n  :  int) 
requires  adm(ch,  n) 


Finally,  we  have  to  give  meaning  to  this  predicate.  This  is  done  by  encoding  the  confidentiality 
policy  into  the  background  predicate  (see  Section  7.2.4).  Since  there  is  only  one  clause  in  our 
example  policy,  we  extend  BackgroundPred  with  the  axiom: 

V  X,  y,  c,  c',  ix,Px,iy,ix-  {readSecret{c' ,  x,  ix,Px)  A 

process {x,y,iy,py)  A 
val{py)  =  true) 
adm(c,  iy) 
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Indirect  Leaks  As  expected,  illegal  direct  leaks  can  be  discovered  rather  straightforwardly  using 
the  annotated  semantics.  In  order  to  verify  the  absence  of  indirect  leaks,  however,  we  cannot  simply 
play  around  with  method  specifications.  The  verification  has  to  make  sure  that  the  flow  of  infor¬ 
mation  is  sfable  under  permufafion  of  secrefs.  Alfhough  fhere  is  no  need  fo  acfually  permufe  secref 
inpufs,  we  still  have  fo  inserf  checks  af  every  pofenfially  branching  poinf. 

The  main  idea  here  is  fo  define  an  specification  predicafe,  stable{e)  which  defermines  whefher  fhe 
values  (fhaf  language  expression  e  may  evaluafe  fo)  vary  or  nof,  whenever  fhe  secref  inpufs  are 
permufed  according  fo  fhe  confidenfialify  policy. 

In  our  running  example, 

y  x,y,c' ,ix,Px,iy,ix-  {readSecret{c' ,  x,ix,Px)  /\  process (x,y,iy,py))  ^  stable{py)  (5) 

fells  us  fhat  we  are  inferesfed  in  permufafions  of  fhe  secrets  that  preserve  the  decisions  made  by 
method  process  regarding  whether  to  allow  the  leakage  or  not  of  the  processed  data. 

Naturally,  we  will  have  to  extend  the  definition  of  predicate  stable  with  several  other  axioms  to 
make  it  useful.  In  order  to  deem  stable  all  constant  expressions,  we  have  the  axiom 

yx.  stable{ct{x))  (6) 

It  is  also  useful  to  relate  a  stable  boolean  expression  to  its  negation. 

yx.  {stable{x)  =  stable{^x))  (7) 

We  turn  our  attention  to  a  piece  of  code,  written  in  OGCL,  and  how  to  enforce  stability  of  branching 
conditions.  Consider  the  following  method  declaration  and  implementation 

method  main (self  :  ob j ) 

impl  main (self  :  ob j )  is 
var 

d  :  Data, 
ch  :  Channel , 
n  :  int 
in 

ch  new ( Channel ) ; 

d  readSecret (ch) ; 

n  :  =  0  ; 

d  : =  process (d) ; 
if 

assume  public [d] ; 
writelnt(ch,  infold]) 

[] 

assume  not (public [d] ) ; 
writeint (ch,  n) 
fi 
end 
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In  this  simple  example,  we  just  have  to  concentrate  on  the  two  partial  commands  for  possible 
perturbations  of  control  flow  under  secret  permutation.  For  each  assume  E,  we  insert  an  assertion 
of  the  form  assume  stable {tr{E)).  Some  care  must  be  taken,  however,  not  to  insert  these  new 
statements  in  places  where  they  might  affect  the  guards  of  commands.  In  the  code  above,  we  are 
forced  to  make  these  insertions  just  before  the  alternative  command.  The  resulting  code,  with  the 
suggested  modifications,  looks  like: 

impl  main (self  :  ob j )  is 
var 

d  :  Data, 
ch  :  Channel , 
n  :  int 
in 

ch  new ( Channel ) ; 
d  readSecret (ch) ; 

n  :  =  0  ; 

d  : =  process (d) ; 
assert  public [d]; 
assert  not (public [d] ) ; 
if 

assume  public [d] ; 
writelnt(ch,  infold]) 

[] 

assume  not (public [d] ) ; 
writeint (ch,  n) 
fi 
end 

Notice  that  we  could  drop  the  second  assertion,  as  it  is  derivable  from  the  first  one  using  axiom  (7). 
But  this  is  just  an  optimization.  Moreover,  the  use  of  code  transformations  should  be  taken  just  as 
an  aid  for  initial  experimentation.  (We  understand  that  an  efficient  implementor  may  instead  prefer 
to  modify  the  verification  condition  predicate  transformer  for  the  partial  command.  The  advantages 
of  this  other  approach  will  be  investigated  in  the  near  future).  For  comparison.  Tables  2  and  3  show 
the  code  of  our  main  example  program  before  and  after  being  transformed. 


Two  wrong  implementations  Our  tool  is  able  to  verify  Admissibility  for  the  implementation  of 
the  main  method  above.  It  can  also  detect  direct  leaks  like  in  this  version 

impl  main (self  :  ob j )  is 
var 

d  :  Data, 
e  :  Data, 
ch  :  Channel 
in 
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ch  new ( Channel ) ; 
d  :=  readSecret (ch) ; 
e  : =  process (d) ; 
if 

assume  public [e] ; 
writelnt(ch,  info[d]) 

[] 

assume  not (public [e] ) ; 
writeint (ch,  0 ) 
fi 
end 

where  unprocessed  secret  values  are  output  (although  this  only  happens  when  the  data,  once  pro¬ 
cessed,  is  considered  declassifiable). 

The  tool  handles  indirect  leaks  too.  For  example,  it  rejects  this  implementation  of  the  main  method 
which  leaks  information  about  the  unprocessed  secret: 

impl  main (self  :  ob j )  is 
var 

d  :  Data, 
e  :  Data, 
ch  :  Channel 
in 

ch  : =  new ( Channel ) ; 
d  readSecret (ch) ; 
e  : =  process (d) ; 
if 

assume  public[e]  and  (infold]  =  0 ) ; 
writeint (ch,  info[e]) 

[] 

assume  not (public [e] ) ; 
writeint (ch,  0 ) 
fi 
end 

Finally,  observe  that  there  are  many  other  ways  in  which  the  flow  of  control  could  be  affected  by 
changes  in  secret  inputs.  Exceptions  could  be  turned  on  and  off,  and  loops  could  take  more  or  less 
iterations  to  terminate  (or  not  terminate  at  all),  etc.  In  most  cases,  the  needed  checks  for  stability 
can  be  inserted  without  problems. 

7.4  Implementation 

We  have  implemented  a  verification  condition  generator  for  OGCL,  using  approximately  7000  lines 
of  OCaml  code  (including  comments  and  approximately  4500  lines  generated  automatically  by 
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the  OCaml  lexer  and  parser  generators).  It  produces  output  for  the  Simplify  theorem  prover  [7] 
which,  once  fed  with  the  encoding  of  the  confidentiality  policy,  will  try  to  validate  the  verification 
conditions  for  every  method  in  the  OGCL  code.  The  tool,  although  still  in  a  debugging  stage,  can 
already  be  used  as  an  experimentation  bench  for  different  encodings  of  policies  and  tracking  of 
secret  data.  In  the  near  future,  we  plan  to  automatize  the  introduction  of  verification  assertions 
for  admissibility  and  experiment  with  implementations  of  increasing  complexity.  Performance  is 
expected  to  become  an  important  issue  then.  There  are  several  optimizations  we  can  apply,  like  code 
transformations  tailored  at  out  particular  verification  condition  generator  (c.f.  [9])  and  alternative 
ways  to  handle  term  substitutions  in  the  logic  (c.f.  [1]). 

Our  experience  has  contributed  arguments  for  the  feasibility  of  a  practical  verifier  of  admissibility 
properties.  Moreover,  we  have  studied  how  to  extend  our  prototype  tool  to  the  complete  Java  Card 
language.  With  this  objective,  we  have  constructed  a  decompiler  based  on  the  Dava  decompiler, 
developed  at  McGill  University,  to  decompile  JavaCard  Virtual  Machine  code  into  the  guarded 
command  language  used  as  input  to  our  verification  condition  generator  [3].  This  approach  would 
permit  the  verification  of  smart  card  applets  whose  source  code  is  not  available. 


8  Related  Work 

Most  studies  of  security  and,  in  particular,  confidentiality  have  remained  essentially  theoretical 
(see  [28]  for  a  recent  survey).  Besides  the  already  mentioned  Java  Information  Flow  (Jif)  tool,  few 
practical  schemes  have  been  developed  and  applied  to  the  full  Java  language  with  the  purpose  of 
verifying  information  properties. 

While  we  have  restricted  our  study  to  single  Java  Card  applets,  Bieber  et  al.  have  analyzed  the 
verification  of  standard  non-interference  properties  of  multi-applet  interactions  [2].  Their  PACAP 
tool  [27]  operates  at  the  level  of  byte  code.  It  inputs  code  for  different  applications  intended  to 
cooperate  within  the  same  smart  card,  and  produces  an  abstract  model  that  can  then  be  verified  using 
the  SMV  model  checker.  The  actual  security  property  to  be  verified  is  expressed  as  a  traditional 
flow  restriction  over  an  MLS  lattice. 

A  different  tool  for  the  verification  of  inter-applet  interactions  is  described  in  [4].  In  this  case,  the 
control  flow  graph  of  a  set  of  applets  is  extracted  from  their  source  (Java  Card)  code,  and  then 
translated  into  a  pushdown  system  for  which  the  model-checking  problem  for  Linear  Temporal 
Logic  (LTL)  is  decidable.  Reasoning  at  the  level  of  the  control  flow  graph  makes  it  possible  to 
specify  properties  (in  LTL)  that  imply,  although  quite  indirectly,  useful  confidentiality  properties. 
The  control-flow  model  abstracts  data  and  therefore  lacks  the  information  needed  to  reason  about 
declassifications. 


9  Conclusions 

During  the  course  of  the  project  we  have  studied  the  verification  of  confidentiality  of  real  mobile 
code.  As  a  test  architecture  we  have  used  Java  Card  smart  cards,  a  choice  that  has  presented  several 
advantages.  First,  the  concerns  regarding  the  secrecy  properties  of  smart  card  applications  are 
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definitively  real,  turning  this  study  into  much  more  than  a  simple  exercise.  The  relatively  small  size 
of  the  Java  Card  architecture  has  permitted  the  construction  of  the  necessary  models  of  the  Java 
Card  API  (moreover,  in  some  cases  the  model  was  readily  available).  Finally  although  Java  Card 
is  a  cut-down  version  of  the  Java  language  it  preserves  most  of  the  challenges  that  characterize  the 
verification  of  object-oriented  programs. 

We  have  evaluated  the  state-of-the-art  in  Java  Card  verification.  Our  case  study  was  developed  with 
a  simple  idea  in  mind:  to  set  up  a  real  verification  situation,  and  see  how  far  we  could  get  with 
existing  analysis  tools.  Currently  available  tools  have  proved  quite  appropriate  to  verify  MLS  mod¬ 
els  of  confidentiality  for  Java  Card  applets,  but  it  is  known  that  these  models  have  serious  practical 
limitations.  In  our  case  study  we  have  actually  encountered  the  “label  creeping”  problem,  and  we 
have  argued  that,  in  practice,  it  is  absolutely  critical  to  be  able  to  model  and  justify  declassification. 

Admissible  interference  is  our  response  to  this  challenge,  as  a  theoretical  model  capable  of  accom¬ 
modating  declassifications  of  data  and  control.  Our  simple  verification  tool  for  admissibility  is  a 
first  step  toward  the  application  of  this  theory  in  practical  situations.  More  work  will  be  needed 
to  scale  it  up  to  the  applications  and  languages  used  in  the  described  case  study.  However,  we 
have  suggested,  by  means  of  our  prototype  tool,  that  such  an  enterprise  could  start  by  combining 
two  existing  technologies,  each  quite  successful  in  its  own  domain:  a  label  model  and  a  weakest- 
precondition  semantics. 
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A  Project  Achievements 


In  the  course  of  the  project  the  following  achievements  have  been  made: 

•  We  have  proposed  a  new  approach,  admissible  interference,  to  non-interference  in  the  pres¬ 
ence  of  information  downgrading  and  cryptographic  operations  which  is  suitable  for  mobile 
code  applications.  In  Pablo  Giambiagi’s  lie.  tech,  thesis  [11],  we  examine  the  basics  of  ad¬ 
missible  interference,  using  a  special-purpose  process  algebra.  In  the  thesis,  an  unwinding 
theorem  is  obtained,  and  links  to  a  The  thesis  also  investigates  an  infrastructure  showing  how 
admissibility  can  be  used  in  practice  to  ensure  confidentiality  aspects  of  mobile  code.  This 
reports  on  our  experiences  with  Java,  web  browsers  and  proof-carrying  code,  and  addresses 
subtleties  in  the  definition  of  an  adequate  user  interface. 

•  In  the  paper  [14]  (full  version  [15]  selected  for  a  special  journal  issue)  extends  the  work 
of  Giambiagi’s  licentiate  thesis  by  showing  how  admissibility  can  be  applied  to  a  simple 
imperative  scripting-like  language  based  on  Dijkstra’s  guarded  commands.  The  language  is 
given  special  annotated  semantics  to  which  admissibility  and  the  unwinding  theorem  can  be 
applied.  A  number  of  examples  have  been  studied  including  a  rudimentary  payment  protocol, 
a  declassifier  aufhorising  clienfs  fo  release  confidenfial  informafion,  and  a  securify  protocol. 

•  A  profofype  verification  condifion  generafor  has  been  developed  which  enforces  admissibilify 
for  programs  wriffen  in  fhe  guarded  command  language.  This  is  reporfed  in  fhe  nofe  [12]. 

•  Admissibility  have  been  applied  to  JavaCard  in  several  ways.  We  have  applied  admissibil¬ 
ity  to  prove  noninterference  properties  of  a  PKCS#1 1  public  key  signature  applet  publicly 
available  from  Dallas  Semiconductors  [5] . 

•  We  have  constructed  a  decompiler  based  on  the  Dava  decompiler,  developed  at  McGill  Uni¬ 
versity,  to  decompile  JavaCard  Virtual  Machine  code  into  the  guarded  command  language 
used  as  input  to  our  verification  condition  generator  [3].  The  main  case  study  studied  within 
this  activity  has  been  the  JavaCard  implementation  of  the  Needham-Schroeder-Lowe  public 
key  protocol  also  addressed  in  this  final  report. 

•  Influenced  by  fhe  PKCS#1 1  case  study  it  has  emerged  that  the  policy  specification  language 
introduced  in  [14]  is  not  quite  expressive  enough  to  handle  realistic  applets.  We  are  therefore 
working  to  replace  the  confidentiality  policies  introduced  in  [14]  with  more  general  flow 
automata,  a  variation  on  Schneider’s  security  automata.  The  modifications  to  the  verifier, 
corresponding  to  this  new  approach,  are  described  in  [13].  item  In  collaboration  with  Dr. 
Martin  Strecker  at  Technical  University  Munich  we  have  started  work  toward  a  static  analysis 
for  admissibility  taking  the  form  of  a  JCVM  type  system.  At  a  first  stage,  we  have  investigated 
the  use  of  automata  to  specify  multilevel  security  policies  (i.e.  noninterference)  and  their 
relation  with  well-established  type  systems  for  noninterference. 

•  We  have  examined  the  general  prospects  for  supporting  confidentiality  for  JavaCard  applets 
in  practice  using  admissibility  and  other  state  of  the  art  tools  ,  in  particular  the  Jif  tool  from 
Cornell  and  the  ESC/Java  tool.  This  is  reported  in  the  present  final  report. 
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B  Source  Code  of  the  NSLClient  Applet 


import  javacard.framework.*; 
import  javacard.security.*; 
import  javacardx. crypto.*; 

public  class  NSLClient  extends  Applet  { 

final  static  byte  STATEJNIT  =  (byte)  0; 

final  static  byte  STATE.WAITING  =  (byte)  1; 

final  static  byte  STATE  CHAT.T.ENCiTNG  =  (byte)  2; 


final  static  short  KEY_LENGTH_BITS  =  KeyBuilder.LENGTH_RSA_512: 
final  static  short  KEY.LENGTH  =  (short)(KEY_LENGTH_BITS/(short)8); 

//  n  byte  nonces. 

//  Should  be  8,  16  or  24  to  allow  use  as  DES  key. 

//  KEY  .LENGTH  >  2*NONCE.  l.F.NGTH  is  required. 

final  static  short  NONCE.LENGTH  =  (short)  16; 

final  static  short  MESSAGE  T.ENGTH  =  (short)((short)2  +  KEY  .LENGTH); 


private  byte  state; 
private  byte[]  inBuf; 
private  byte[]  outBuf,  nonce; 

private  byte  appletID; 
private  byte  serverlD; 

private  final  byte[]  secret  =  {(byte)'S', 

(byte) '  E ' , 
(byte) '  C ' , 
(byte)'R', 
(byte) '  E ' , 
(byte) '  T ' , 
(byte)'  .  '}; 

private  Cipher  enc; 
private  Cipher  dec,  sCipher; 

private  RSAPublicKey  server_public_key; 
private  DESKey  temp.key; 
private  RandomData  rand; 

private  RSAPrivateKey  my_private_key; 


//  Constructor,  sets  initial  state. 

protected  NSLClient(byte[]  bArray,  short  bOffset,  byte  bLength) 
throws  SystemException,  CryptoException 

{ 
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state  =  STATEJNIT; 


appletID  =  b  Array  [bOffset]; 
serverlD  =  bArray[b0ffset+1  ]; 

inBuf  =  JCSystem.makeTransientByteArray 

(MESSAGE_LENGTH,  JCSystem.CLEAR.ON .DESELECT); 
outBuf  =  JCSystem.makeTransientByteArray 

(MESSAGE_LENGTH,  JCSystem.CLEAR.ON .DESELECT); 
nonce  =  JCSystem.makeTransientByteArray 

(NONCE.LENGTH,  JCSystem.CLEAR.ON.DESELECT); 

my.private.key  =  (RSAPrivateKey)KeyBuilder.buildKey 

(KeyBuilder.TYPE.RSA.PRIVATE, 
KEY.LENGTH.BITS,  false); 

server.public.key  =  (RSAPublicKey) 

KeyBuilder.buildKey 

(KeyBuilder.TYPE.RSA.PUBLIC, 
KEY.LENGTH.BITS,  false); 

//  MISSING:  KEY  INITIALIZATION  FOR  RSA  KEYS! 

temp.key  =  (DESKey)KeyBuilder.buildKey 

(KeyBuilder.TYPE.DES.TRANSIENTJDESELECT, 
KeyBuilder.LENGTH.DES3.2KEY,  false); 


rand  =  RandomData.getInstance 

(RandomData.  ALG.SECURE.RANDOM) ; 

dec  =  Cipher.getInstance(Cipher.ALG.RSA.PKCSL  false); 
enc  =  Cipher.getInstance(Cipher.ALG.RSA.PKCSL  false); 
sCipher  =  Cipher.getInstance(Cipher.ALG.DES.CBC.PKCS5, 

false); 

enc.init(server.public.key,  Cipher. MODE.ENCRYPT); 
dec.init(my.private.key,  Cipher.MODE.DECRYPT); 


} 


//  Installation  routine 

public  static  void  install(byte[  ]  bArray,  short  bOffset,  byte  bLength) 
throws  ISOException,  SystemException 

{ 

try{ 

(new  NSLClient(bAn-ay,  bOffset,  bLength)). register(); 

} 

catch  (CryptoException  e)  { 

ISOException.throwIt(lS07816.SW.UNKNOWN); 

} 

} 


//  Reset  on  each  new  selection 

public  boolean  select()  { 
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} 


state  =  STATEJNIT; 

return  true; 


//  Main  call-in  point. 

public  void  process(APDU  apdu) 

throws  ISOException,  APDUException,  CryptoException 

{ 

switch(state)  { 

case  STATEJNIT:  sendld(apdu);  break; 
ease  STATE_WAITING:  sendChallenge(apdu);  break; 
ease  STATE  CHAT.TE.NGTNG:  sendSecret(apdu);  break; 
default:  state  =  STATEJNIT; 

ISOException.throwIt(IS07816.SW_EUNC_NOT_SUPPORTED); 

} 

} 


//  A  ->  S:  A 

private  void  sendId(APDU  apdu) 
throws  APDUException 

{ 

apdu.getBuffer()[0]  =  appletID; 
apdu.setOutgoingAndSend((short)0,(short)1); 
state  =  STATE.WAITING; 


//  S  ->  A;  (S.  A,  {n,  S}J’ub(A)) 

//  A  ->  S:  (A.  S,  {n,  m,  A}J>ub(S)) 
private  void  sendChallenge(APDU  apdu) 

throws  ISOException,  CryptoException,  APDUException 

{ 

state  =  STATEJNIT; 

getMessage(apdu);  //  Get  the  challenge. 

//  Check  S  and  A  in  the  clear 

if(inBuf[0]  !=  serverlD  |  |  inBuf[1]  !=  appletID) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUS_N0T  .SATISFIED); 
//  Decrypt  the  encrypted  part. 

dec.doFinal(inBuf,  (short)2,  KEY.LENGTH,  outBuf,  (short)2); 

//  Check  S  in  the  encrypted  part. 
if(outBuf[NONCE_LENGTH+2]  !=  serverlD) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUSJ^0T  .SATISFIED); 

//  Build  the  encrypted  part  of  response. 
rand.generateData(nonce,  (short)O,  NONCE.LENGTH); 
Util.arrayCopyNonAtomic(nonce,  (short)O, 
outBuf, 
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(short)  (NONCE_LENGTH+(short)2) , 
NONCE_LENGTH); 

outBuf[NONCE_LENGTH*2+2]  =  outBuf[1]; 

//  Encrypt  the  encrypted  part  of  response. 
enc.doEinal(outBuf,  (short)2, 

(short)(((short)2)*NONCE_LENGTH  +  (short)1), 
outBuf,  (short)2); 

//  Fill  in  clear  text  part  of  response. 
outBuf[0]  =  appletID; 
outBuf[1]  =  serverlD; 

//  Send  the  response. 

sendMessage(apdu,  outBuf,  (short)O,  MESSAGE_LENGTH); 
state  =  STATE.CHALLENGING; 


//  S  ->  A;  (S,  A,  {m}_Pub(A)) 

/7  A  ->  S:  {secret} 

private  void  sendSecret(APDU  apdu) 

throws  ISOException,  CryptoException,  APDUException 

{ 

state  =  STATEJNIT; 

getMessage(apdu);  //  Get  the  challenge. 

//  Check  S  and  A  in  the  clear 

if(inBuf[0]  !=  serverlD  |  |  inBuf[1]  !=  appletID) 

ISOException.  throwit 

(IS078I6.SW_SECURITY_STATUS_N0T  .SATISFIED); 

//  Decrypt  the  encrypted  part. 

dec.doFinal(inBuf,  (short)2,  KEY.LENGTH,  outBuf,  (short)O); 

//  Compare  the  nonces. 

for(short  i  =  0;  i  <  NONCE_LENGTH;  i++) 
if(nonce[i]  !=  outBuf[i]) 

ISOException.  throwit 

(IS078I6.SW_SECURITY_STATUSJ^OT  .SATISFIED); 


//  OK.  we’ve  authenticated. 

//  Now  send  secret,  encrypted  under  our  nonce. 
temp.key.setKey(nonce,  (short)O); 
sCipher.init(temp.key ,  Cipher.MODE.ENCRYPT) ; 
sCipher.doFinal(secret,  (short)O,  (short)secret.length, 
outBuf,  (short)2); 

//  Fill  in  clear  text  part  of  response. 
outBuf[0]  =  appletID; 
outBuf)  1]  =  serverlD; 

//  Send  the  secret. 

sendMessage(apdu,  outBuf,  (short)O,  MESSAGE.LENGTH); 
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state  =  STATEJNIT; 


} 

private  void  getMessage(APDU  apdu) 

throws  ISOException,  APDUException 

{ 

short  nRead  =  0; 

short  nReadNow  =  apdu.setIncomingAndReceive(); 

while  (nReadNow  >  0  && 

nRead  +  nReadNow  <=  MESSAGE_LENGTH)  { 
Util.arrayCopyNonAtomic(apdu.getBuffer(), 

IS07816.0FFSET_CDATA, 
inBuf,  nRead,  nReadNow); 

nRead  +=  nReadNow; 

nReadNow  =  apdu.receiveBytes(IS07816.0FPSET_CDATA); 

} 

if  (nRead  +  nReadNow  !=  MESSAGE_LENGTH) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUS_N0T  .SATISFIED); 


} 

private  void  sendMessage(APDU  apdu,  byte[]  buf,  short  offset, 
short  len) 

throws  APDUException 

{ 

apdu.setOutgoingO; 

apdu.  setOutgoingLength(len) ; 

apdu.sendBytesLong(buf,  offset,  len); 

} 
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C  Jif  Annotation  of  the  NSLClient  Applet 


import  javacard.framework.*; 
import  javacard.security.*; 
import  javacardx. crypto.*; 

public  class  NSLClient[principal  P]  extends  Applet[P]  authority(P)  { 

final  static  byte  STATEJNIT  =  (byte)  0; 
final  static  byte  STATE.WAITING  =  (byte)  1; 
final  static  byte  STATE.CHALLENGING  =  (byte)  2; 


final  static  short  KEY_LENGTH_BITS  =  KeyBuilder.LENGTH_RSA_512: 

/*final*/  static  short  KEY.LENGTH;  //=  (shoi-t)(KEY_LENGTH_BITS/(short)8); 

/*  KEY_LENGTH  should  be  final,  but  the  initializer  may  thrown  an 
Arithmetic  expression,  so  it  has  to  be  given  within  the 
constructor.  However,  when  put  in  the  constructor,  JIF  says 
that  the  initialization  should  be  done  before  invoking  the 
constructor,  and  that  point  of  the  implicit  superclass 
constructor  invocation  is  at  the  very  beginning  (because,  it  says, 
the  superclass,  javacard.framework. Applet  is  NOT  trusted).  Therefore, 
the  initialization  of  this  field  cannot  be  put  here,  nor  nowhere  in 
the  constructor.  What’s  up? 


//  n  byte  nonces. 

//  Should  be  8,  16  or  24  to  allow  use  as  DES  key. 
//  KEY  .LENGTH  >  2*NONCF.  f.ENGTH  is  required. 

final  static  short  NONCE.LENGTH  =  (short)  16; 

final  short  ME.SSAGE  T.ENGTH  =  (short)  ((short)2  +  KEY  .LENGTH); 


private  byte  state; 

private  byte[]  inBuf; 

private  byte{P:}[]{P:}  outBuf,  nonce; 

private  byte  appletID; 
private  byte  serverlD; 

private  final  byte{P:}[]{P:}  secret  =  {(byte) 'S', 

(byte) '  E ' , 
(byte) '  C ' , 
(byte) '  R ' , 
(byte) '  E ' , 
(byte) '  T ' , 
(byte)'  . 

private  Cipher  enc; 

private  CipherjP:}  dec,  sCipher; 
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private  RSAPrivateKeyjP;}  my_private_key; 
private  RSAPublicKey  server_public_key; 
private  DESKeyjP:}  temp_key; 

private  RandomDatajP:}  rand; 

//  Constructor,  sets  initial  state. 

protected  NSLClient{}(byte[]{}  bArray,  short  bOffset,  byte  bLength):{P:} 
throws  (SystemException,  CryptoException) 

{ 

try  { 

KEY  TE.NGTH  =  (short)(KEY_LENGTH_BITS/(short)8); 
state  =  STATEJNIT; 

appletID  =  bArray[0]; 
serverlD  =  bArray[1]; 

inBuf  =  JCSystem.makeTransientByteArray 

(MESSAGE_LENGTH,  JCSystem.CLEAR.ON .DESELECT); 
outBuf  =  JCSystem.makeTransientByteArray 

(MESSAGE_LENGTH,  JCSystem.CLEAR.ON .DESELECT); 
nonce  =  JCSystem.makeTransientByteArray 

(NONCE.LENGTH,  JCSystem.CLEAR.ON JDESELECT); 


my.private.key  =  (RSAPrivateKey) 

KeyBuilder.buildKey(KeyBuilder.TYPE.RSA.PRIVATE, 
KEY.LENGTH.BITS,  false); 

server.public.key  =  (RSAPublicKey) 

KeyBuilder.buildKey(KeyBuilder.TYPE.RSA.PUBLIC, 
KEY.LENGTH.BITS,  false); 

//  MISSING:  KEY  INITIALIZATION  FOR  RSA  KEYS! 

temp.key  =  (DESKey)KeyBuilder.buildKey 

(KeyBuilder.TYPE.DES.TRANSIENT  JDESELECT, 
KeyBuilder.LENGTH.DES3.2KEY,  false); 


rand  =  RandomData.getInstance 

(RandomData.  ALG.SECURE.RANDOM) ; 

dec  =  Cipher.getInstance(Cipher.ALG.RSA.PKCSl,  false); 
enc  =  Cipher.getInstance(Cipher.ALG.RSA.PKCSl,  false); 
sCipher  =  Cipher.getInstance(Cipher.ALG.DES.CBC.PKCS5, 

false); 

enc.init(server.public.key.  Cipher. MODE.ENCRYPT); 
dec.init(my.private.key,  Cipher.MODE.DECRYPT); 


} 

catch  (NullPointerException  e)  {/*@  unreachable  */} 

catch  (ArithmeticException  e)  {/*@  unreachable  */} 

catch  (ArrayIndexOutOfBoundsException  e)  {/*@  unreachable  V} 
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catch  (ClassCastException  e)  {/*@  unreachable  V} 


} 


//  Installation  routine 

public  static  void  install{}(byte{}[]{}  bArray,  short  bOffset, 

byte  bLength):{P:} 

throws  (ISOException,  SystemException) 

where  authority(P) 

{ 

try{ 

(new  NSLClient[P](bArray,  bOffset,  bLength)).register(); 

} 

catch  (CryptoException  e)  { 

ISOException.throwIt(lS07816.SW_UNKNOWN); 

} 

catch  (NullPointerException  e){/*@  unreachable  */} 

catch  (ArrayIndexOutOfBoundsException  e){/*@  unreachable  */} 


} 


//  Reset  on  each  new  selection 

public  boolean  select{}()  { 
state  =  STATEJNIT; 
return  true; 

} 


//  Main  call-in  point. 

public  void  process{}(APDU{}  apdu):{P:} 

throws  (APDUException,  CryptoException,  ISOException) 

where  authority(P) 

{ 

switch(state)  { 

case  STATEJNIT:  sendld(apdu);  break; 
case  STATE_WAITING:  sendChallenge(apdu);  break; 
case  STATE.CHALLENGING:  sendSecret(apdu);  break; 
default:  state  =  STATEJNIT; 

ISOException.throwIt(IS07816.SW_EUNC_NOT_SUPPORTED); 

} 

} 


//  A  ->  S:  A 

private  void  sendId{}(APDU{}  apdu) 
throws  (APDUException) 

{ 

try  { 

apdu.getBuffer()[0]  =  appletID; 

apdu.  setOutgoingAndSend((short)0,  (short)  1 ) ; 

state  =  STATE.WAITING; 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 
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catch  ( Array IndexOutOfBoundsException  e)  {/*@  unreachable  */} 


//  S  ->  A;  (S,  A,  {«,  S}J'ub(A)) 

//  A  ->  S:  (A,  S,  {n,  m,  A}_Pub(S)) 

private  void  sendChallenge{}(APDU{}  apdu):{P:} 

throws  (CryptoException,  APDUException,  ISOException) 

where  authority(P) 

{ 

try  { 

state  =  STATEJNIT; 

getMessage(apdu);  //  Get  the  challenge. 

//  Check  S  and  A  in  the  clear 

if(inBuf[0]  !=  serverlD  |  |  inBuf[1]  !=  appletID) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUS_NOT  .SATISFIED); 
//  Decrypt  the  encrypted  part. 

dec.doFinal(inBuf,  (short)2,  KEY.LENGTH,  outBuf,  (short)2); 

//  Check  S  in  the  encrypted  part. 
if  (outBuf  [NONCE_LENGTH+2]  !=  serverlD) 

ISOException.  throwit 

(IS078I6.SW_SECURITY_STATUSJ^OT  .SATISFIED); 

//  Build  the  encrypted  part  of  response. 
rand.generateData(nonce,  (short)O,  NONCE.LENGTH); 

Util,  array  Copy  Non  Atomic(nonce,  (short)O, 
outBuf, 

(short)(NONCE.LENGTH+(short)2), 

NONCE.LENGTH); 

outBuf[NONCE.LENGTH*2+2]  =  outBuf[1]; 

//  Encrypt  the  encrypted  part  of  response. 
enc.doFinal(outBuf,  (short)2, 

(short)(((short)2)*NONCEXENGTH  +  (short)l), 
outBuf,  (short)2); 

//  Fill  in  clear  text  part  of  response. 
outBuf[0]  =  appletID; 
outBuf[1]  =  serverlD; 

//  Send  the  response. 

declassify({}){ 

sendMessage(apdu,  declassify(outBuf,  {}), 

(short)O,  MESSAGE  I.ENGTH); 

state  =  STATE.CHALLENGING; 

} 

} 

catch  (NullPointerException  e)  {/*@  unreachable  */} 

catch  (Array IndexOutOfBoundsException  e)  {/*@  unreachable  */} 
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//  S  ->  A;  (S,  A,  {m}_Pub(A)) 

//  A  ->  S:  {secret}_m 

private  void  sendSecret{}(APDU{}  apdu):{P:} 

throws  (CryptoException,  APDUException,  ISOException) 

where  authority(P) 

{ 

try  { 

state  =  STATEJNIT; 

getMessage(apdu);  //  Get  the  challenge. 

//  Check  S  and  A  in  the  clear 

if(inBuf[0]  !=  serverlD  |  |  inBuf[1]  !=  appletID) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUS_NOT_SATISEIED); 

//  Decrypt  the  encrypted  part. 

dec.doEinal(inBuf,  (short)2,  KEY_LENGTH,  outBuf,  (short)O); 

//  Compare  the  nonces. 
for(short  i  =  0;  i  <  NONCE_LENGTH;  i++) 
if(nonce[i]  !=  outBuf[i]) 

ISOException.  throw  It 

(IS078I6.SW_SECURITY_STATUS_N0T_SATISEIED); 


//  OK,  we’ve  authenticated. 

//  Now  send  secret,  encrypted  under  our  nonce. 
temp_k;ey.setKey(nonce,  (short)O); 
sCipher.init(temp_key ,  Cipher.MODE_ENCRYPT) ; 
sCipher.doEinal(secret,  (short)O,  (short)secret.length, 
outBuf,  (short)2); 

//  Fill  in  clear  text  part  of  response. 
outBuf[0]  =  appletID; 
outBuf[1]  =  serverlD; 

//  Send  the  secret. 

declassify({}){ 

sendMessage(apdu,  declassify(outBuf,  {}), 

(short)O,  MESSAGE_LENGTH); 
state  =  STATEJNIT; 

} 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

catch  ( Array IndexOutOfBoundsException  e)  {/*@  unreachable  */} 


private  void  getMessage{}(APDU{}  apdu) 
throws  (APDUException,  ISOException) 

{ 

try  { 

short  nRead  =  0; 

short  nReadNow  =  apdu.setIncomingAndReceive(); 
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while  (nReadNow  >  0  && 

nRead  +  nReadNow  <=  MESSAGE.LENGTH)  { 
Util.arrayCopyNonAtomic(apdu.getBuffer(), 

IS078 16.0FFSET_CDATA, 
inBuf,  nRead,  nReadNow); 

nRead  +=  nReadNow; 

nReadNow  =  apdu.receiveBytes(IS07816.0FFSET_CDATA); 

} 

if  (nRead  +  nReadNow  !=  MESSAGE.LENGTH) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUS_NOT  .SATISFIED); 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

catch  ( Array IndexOutOfBoundsException  e)  {/*@  unreachable  V} 

} 

private  void  sendMessage{}(APDU{}  apdu,  hyte{}[]{}  buf,  short{}  offset, 

short{}  len) 

throws  (APDUException) 

{ 

try  { 

apdu.  setOutgoingO ; 

apdu.  setOutgoingLength(len) ; 

apdu.sendBytesLong(buf,  offset,  len); 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

} 

} 
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D  ESC/Java  Annotation  of  the  NSLClient  Applet 


import  javacard.framework.*; 
import  javacard.security.*; 
import  javacardx. crypto.*; 

public  class  NSLClient  extends  Applet  { 

final  static  byte  STATEJNIT  =  (byte)  0; 

final  static  byte  STATE.WAITING  =  (byte)  1; 

final  static  byte  STATE  CHAT.T.ENCiTNG  =  (byte)  2; 

final  static  short  KEY_LENGTH_BITS  =  KeyBuilder.LENGTH_RSA_512: 

final  static  short  KEY.LENGTH  =  (short)(KEY_LENGTH_BITS/(short)8); 

//  n  byte  nonces. 

//  Should  be  8,  16  or  24  to  allow  use  as  DES  key. 

//  KEY  I.F.NGTH  >  2*NONCE  l.ENGTH  is  required. 

final  static  short  NONCE.LENGTH  =  (short)  16; 

final  static  short  MESSAGE  l.ENGTH  =  (short)((short)2  +  KEY  .LENGTH); 


private  /*@  spec-public  */  byte  state; 
private  byte[]  inBuf; 
private  byte[]  outBuf,  nonce; 

private  byte  appletID; 
private  byte  serverlD; 

private  final  byte[]  secret  =  {(byte)'S', 

(byte) '  E ' , 
(byte) '  C ' , 
(byte)'R', 
(byte) '  E ' , 
(byte) '  T ' , 
(byte)'  . 

private  Cipher  enc; 
private  Cipher  dec,  sCipher; 

private  RSAPublicKey  server_public_key; 
private  DESKey  temp.key; 
private  RandomData  rand; 

private  RSAPrivateKey  my_private_key; 


/*@  invariant 

@  (state  ==  STATEJNIT  \  \  state  ==  STATE  .WAITING  \  \ 

@  state  ==  STATE.CHALLENGING) 

@  &&  inBuf  .'=  null  &&  inBuf. length  ==  MESSAGE  l.ENGTH 

@  &&  outBuf  !-  null  &&  outBuf.length  --  MESSAGE J^ENGTH 
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@  &&  nonce  !-  null  &&  nonce. length  ==  NONCE_LENGTH 

@  &&  dec  /=  null 
@  &&  enc  /=  null 
@  &&  rand  I-  null 

@y 

//  Constructor,  sets  initial  state. 

/*@  requires 

@  0  <-  bOJfset  &&  bLength  >=  2  &&  bArray  /=  null 

@  &&  bOjfset  +  bLength  <  bArray.length; 

@  V 

protected  NSLClient(byte[]  bArray,  short  bOffset,  byte  bLength) 
throws  SystemException,  CryptoException 

{ 

try  { 

state  =  STATEJNIT; 

appletID  =  bArray[bOffset]; 
serverlD  =  bArray[bOffset+1]; 

inBuf  =  JCSystem.makeTransientByteArray 

(MESSAGE_LENGTH,  JCSystem.CLEAR.ON .DESELECT); 
outBuf  =  JCSystem.makeTransientByteArray 

(MESSAGE_LENGTH,  JCSystem.CLEAR.ON  JDESELECT); 
nonce  =  JCSystem.makeTransientByteArray 

(NONCE_LENGTH,  JCSystem.CLEAR.ON JDESELECT) ; 

my_private_key  =  /*@  nowarn  Cast  */  (RSAPrivateKey) 
KeyBuilder.buildKey(KeyBuilder.TYPE_RSA_PRIVATE, 
KEY_LENGTH_BITS,  false); 

server. public.key  =  /*@  nowarn  Cast  V  (RSAPublicKey) 
KeyBuilder.buildKey(KeyBuilder.TYPE.RSA.PUBLIC, 
KEY.LENGTH.BITS,  false); 

//  MISSING:  KEY  INITIALIZATION  EOR  RSA  KEYS! 

temp.key  =  /*@  nowarn  Cast  V  (DESKey) 

KeyBuilder.buildKey 

(KeyBuilder.TYPE.DES.TRANSIENTJDESELECT, 
KeyBuilder.LENGTH.DES3.2KEY,  false); 


rand  =  RandomData.getInstance 

(RandomData.  ALG.SECURE.RANDOM) ; 

dec  =  Cipher.getlnstance(Cipher.ALG.RSA.PKCSl,  false); 
enc  =  Cipher.getlnstance(Cipher.ALG.RSA.PKCSl,  false); 
sCipher  =  Cipher.getInstance(Cipher.ALG.DES.CBC.PKCS5, 

false); 

enc.init(server.public.key.  Cipher. MODE.ENCRYPT); 
dec.init(my.private.key.  Cipher. MODE.DECRYPT); 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 
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catch  (ArithmeticException  e)  {/*@  unreachable  */} 

catch  (ArrayIndexOutOfBoundsException  e)  {/*@  unreachable  V} 

catch  (ClassCastException  e)  {/*@  unreachable  V} 


//  Installation  routine 
/*@  requires 

@  0  <-  bOjfset  &&  bLength  >=  2  &&  bArray  /=  null 

@  &&  bOjfset  +  bLength  <  bArray.length 

@*/ 

public  static  void  install(byte[  ]  bArray,  short  bOffset,  byte  bLength) 
throws  ISOException,  SystemException 

{ 

try{ 

(new  NSLClient(bArray,  bOffset,  bLength)). register(); 

} 

catch  (CryptoException  e)  { 

ISOException.throwIt(lS07816.SW_UNKNOWN); 

} 

catch  (NullPointerException  e){/*@  unreachable  V} 

catch  (ArrayIndexOutOfBoundsException  e){/*@  unreachable  */} 


//  Reset  on  each  new  selection 

/*@  also_ensures  state  ==  STATE JNIT; 

@  modifies  state; 

@*/ 

public  boolean  select()  { 
state  =  STATEJNIT; 

return  true; 

} 

//  Main  call-in  point. 

/*@  requires  apdu  !=  null  &&  apdu._APDU-State  ==  1; 

@  modifies 

@  state,  apdu.bufferf*],  inBuf[*],  outBufl*],  noncef*]; 

@  exsures  (Exception)  state  --  STATEJNIT; 

@*/ 

public  void  process(APDU  apdu) 

throws  ISOException,  APDUException,  CryptoException 

{ 

switch(state)  { 

case  STATEJNIT:  sendld(apdu);  break; 
case  STATE_WAITING:  sendChallenge(apdu);  break; 
case  STATE  CHAT.T.ENC.TNG:  sendSecret(apdu);  break; 
default:  state  =  STATEJNIT; 

ISOException.throwIt(IS07816.SW_EUNC_NOT_SUPPORTED); 

} 

} 


//  A  ->  S;  A 
/*@  requires 

@  apdu  !=  null  &&  apdu.-APDUstate  ==  1 
@  &&  state  ==  STATEJNIT; 

@  modifies 
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@  state,  apdu.buffer[*]; 

@  ensures 

@  state  ==  STATEJVAITING: 

@  exsures  (Exception)  state  --  STATE JNIT; 

@*/ 

private  void  sendId(APDU  apdu) 
throws  APDUException 

{ 

try  { 

apdu.getBuffer()[0]  =  appletID; 

apdu.  setOutgoingAndSend((short)0,  (short)  1 ) ; 

state  =  STATE.WAITING; 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

catch  ( Array IndexOutOfBoundsException  e)  {/*@  unreachable  V} 


//  S  ->  A:  (S.  A,  {n,  S}J>ub(A)) 

//  A  ->  S:  (A.  S,  {n,  m,  A}J>ub(S)) 

/*@  requires 

@  apdu  !=  null  &&  apdu._APDUstate  -=  1 
@  &&  state  ==  STATE  .WAITING: 

@  modifies 

@  state,  apdu.bufferf*],  inBuff*],  outBufl*],  noncef*]; 

@  ensures 

@  state  ==  STATE.CHALLENGING; 

@  exsures  (Exception)  state  --  STATE  JNIT; 

@*/ 

private  void  sendChallenge(APDU  apdu) 

throws  ISOException,  CryptoException,  APDUException 

{ 

try  { 

state  =  STATEJNIT; 

getMessage(apdu);  //  Get  the  challenge. 

//  Check  S  and  A  in  the  clear 

if(inBuf[0]  !=  serverlD  |  |  inBuf[1]  !=  appletID) 

ISOException.  throwit 

(IS078I6.SW_SECURITY_STATUS_NOT  .SATISFIED); 
//  Decrypt  the  encrypted  part. 

dec.doFinal(inBuf,  (short)2,  KEY.LENGTH,  outBuf,  (short)2); 

//  Check  S  in  the  encrypted  part. 
if  (outBuf  [NONCE_LENGTH+2]  !=  serverlD) 

ISOException.  throwit 

(IS078I6.SW_SECURITY_STATUS3fOT  .SATISFIED); 

//  Build  the  encrypted  part  of  response. 
rand.generateData(nonce,  (short)O,  NONCE.LENGTH); 

Util .  array  Copy  Non  Atomic  (nonce ,  (short)  0 , 
outBuf, 

(short)(NONCE.LENGTH+(short)2), 

NONCE.LENGTH); 
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outBuf[NONCE_LENGTH*2+2]  =  outBuf[1]; 


//  Encrypt  the  encrypted  part  of  response. 
enc.doFinal(outBuf,  (short)2, 

(short)(((short)2)*NONCEXENGTH  +  (short)1), 
outBuf,  (short)2); 

//  Fill  in  clear  text  part  of  response. 
outBuf[0]  =  appletID; 
outBuf[1]  =  serverlD; 

//  Send  the  response. 

//decla.wify(  {} ){ 

sendMessage(apdu,  /*declassify( */outBuf/*,  {})*/, 

(short)O,  MESSAGE  T.ENGTH); 

state  =  STATE.CHALLENGING; 

//} 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

catch  (ArrayIndexOutOfBoundsException  e)  {/*@  unreachable  V} 


//  S  ->  A:  (S,  A,  {m}_Pub(A)) 

//  A  E>  S:  {secret} 

/*@  requires 

@  apdu  /=  null  &&  apdu._APDU-State  -=  1 
@  &&  state  ==  STATE  CHAI.I.ENGING; 

@  modifies 

@  state,  outBuff*],  apdu.bufferf*],  inBuf[*]: 

@  ensures 

@  state  ==  STATE  JNIT; 

@  exsures  (Exception)  state  ==  STATE  JNIT: 

@*/ 

private  void  sendSecret(APDU  apdu) 

throws  ISOException,  CryptoException,  APDUException 

{ 

try  { 

state  =  STATEJNIT; 

getMessage(apdu);  //  Get  the  challenge. 

//  Check  S  and  A  in  the  clear 

if(inBuf[0]  !=  serverlD  |  |  inBuf[1]  !=  appletID) 

ISOException.  throwit 

(IS078I6.SW_SECURITY_STATUS_NOT  .SATISFIED); 
//  Decrypt  the  encrypted  part. 

dec.doFinal(inBuf,  (short)2,  KEY.LENGTH,  outBuf,  (short)O); 

//  Compare  the  nonces. 
for(short  i  =  0;  i  <  NONCE_LENGTH;  i++) 
if(nonce[i]  !=  outBuf[i]) 

ISOException.  throwit 
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(IS07816.SW_SECURITY_STATUS_N0T  .SATISFIED); 

//  OK,  we’ve  authenticated. 

//  Now  send  secret,  encrypted  under  our  nonce. 
temp_k;ey.setKey(nonce,  (short)O); 
sCipher.init(temp_key ,  Cipher.MODE.ENCRYPT) ; 
sCipher.doFinal(secret,  (short)O,  (short)secret.length, 
outBuf,  (short)2); 

//  Fill  in  clear  text  part  of  response. 
outBuf[0]  =  appletID; 
outBuf[1]  =  serverlD; 

//  Send  the  secret. 

//declassify({}){ 

sendMessage(apdu,  /*dec7asj!/yf VoutBuf/*,  {})*/, 

(short)O,  MESSAGE_LENGTH); 
state  =  STATEJNIT; 

//} 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

catch  ( Array IndexOutOfBoundsException  e)  {/*@  unreachable  V} 


/*@  requires 

@  apdu  /=  null  &&  apdu._APDUstate  ==  1; 

@  modifies 

@  iiiBufl*],  apdu.bufferf*] 

@*/ 

private  void  getMessage(APDU  apdu) 

throws  ISOException,  APDUException 

{ 

try  { 

short  nRead  =  0; 

short  nReadNow  =  apdu.setIncomingAndReceive(); 

while  (nReadNow  >  0  && 

nRead  +  nReadNow  <=  MESSAGE.LENGTH)  { 
Util.arrayCopyNonAtomic(apdu.getBuffer(), 

IS07816.0FFSET_CDATA, 
inBuf,  nRead,  nReadNow); 

nRead  +=  nReadNow; 

nReadNow  =  apdu.receiveBytes(IS07816.0FFSET_CDATA); 

} 

if  (nRead  +  nReadNow  !=  MESSAGE.LENGTH) 

ISOException.  throwit 

(IS07816.SW_SECURITY_STATUSJ8fOT  .SATISFIED); 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

catch  (Array IndexOutOfBoundsException  e)  {/*@  unreachable  V} 


/*@  requires 

@  apdu  !=  null  &&  apdu._APDUstate  ==  1 
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@  &&  0  <=  len  &&  len  <  256  &&  0  <=  ojfset  &&  buf  !=  null 

@  &&  ojfset  +  len  <=  buf.  length; 

@  modifies 
@  apdu.bufferj*] 

@  V 

private  void  sendMessage(APDU  apdu,  byte[]  buf,  short  offset, 
short  len) 

throws  APDUException 

{ 

try  { 

apdu.  setOutgoingO ; 

apdu.  setOutgoingLength(len) ; 

apdu.sendBytesLong(buf,  offset,  len); 

} 

catch  (NullPointerException  e)  {/*@  unreachable  V} 

} 


57 


type  Data 

field  info  :  Data  ->  int 
field  public  :  Data  ->  bool 

method  e  :  Data  process (d  :  Data) 
ensures  fresh(e) 


/***/ 

type  Channel 

method  d  :  Data  readSecret (ch  :  Channel) 
ensures  fresh (d)  and  public [d]  =  false 

method  writelnt(ch  :  Channel,  n  :  int) 

/***/ 

method  main (self  :  ob j ) 

impl  main (self  :  ob j )  is 
var 

d  :  Data, 
ch  :  Channel , 
n  :  int 
in 

ch  new ( Channel ) ; 

d  readSecret (ch) ; 
n  :  =  0  ; 

d  : =  process (d) ; 
if 

assume  public [d] ; 
writelnt(ch,  info[d]) 

[] 

assume  not (public [d] ) ; 
writeint (ch,  n) 
fi 
end 


Table  2:  OCGL  example  program 
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type  Data 

field  info  :  Data  ->  int 
field  public  :  Data  ->  bool 


method  e  :  Data  process (d  :  Data) 
ensures  fresh(e)  and  process (d,  e) 

/  *  *  *  / 

type  Channel 


method  d  :  Data  :  = 
ensures  fresh (d) 


readSecret (ch 
and  public [d] 


Channel ) 

false  and  readSecret (ch,  d) 


method  writelnt(ch 
requires  adm(ch, 


:  Channel , 
n) 


n 


int ) 


/  *  *  *  / 

method  main (self  :  ob j ) 


impl  main (self  :  ob j )  is 
var 

d  :  Data, 
ch  :  Channel , 
n  :  int 
in 

ch  new ( Channel ) ; 
d  readSecret (ch) ; 

n  :  =  0  ; 

d  : =  process (d) ; 

assert  stable (public [d] ) ; 

/*  Obs :  ''assert  stable (not  public [d] )' ' 
is  derivable  using  axiom  (7)  */ 
if 

assume  public [d] ; 
writelnt(ch,  info[d]) 

[] 

assume  not (public [d] ) ; 
writeint (ch,  n) 
fi 
end 


Table  3:  OCGL  example  program  adapted  to  the  verification  of  Admissibility 
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